Closed mayork closed 7 years ago
Taking a look now... will post updates.
I see the Tt4max for 777 is unbounded. What is a good estimate for this parameter?
Btw, this I think might be an odd instance where the 777 gets stuck in a local optimum and isn't able to get out. A little disconcerting, especially since we claim the SP algorithm is so robust. Let me see if I can find more definitive evidence that this is the case.
Also, I have gotten 777 to solve unbounded, but not 737. interesting...
I think I will have to go through the set of substitutions one by one, and see where the discrepancies are, since the set of constraints are the same.
Lolol, I think it is because you put the same limit on the fan diameter on the 73 as for the 77. Oops. Will change and see if that resolves the issues.
This means that BCS has to be back in 777, but the solves are better behaved, but still having relaxed variables. I think this is because the model is having legitimate issues sizing a wing that satisfies the constraints. Looking into it...
The main issue is that our vertical tail sizes out HUUUGE, super heavy and draggy, making the model infeasible... why is it that we cannot get the VT to be the right size? It seems like a very straight-forward thing.
Figured it out. Drela sizes 777 vt using volume coefficient, not engine out moment, resulting in a VT that is 50% smaller. Voila! Will fix and push!
After VT fixes, the wing sizes out much better, but wing drag coefficient is off by 145%. How come this happens? It's driving our overall Cd really high.
And the engine weight is off 60%, likely because of the 47% high CD. @mayork, would you look into this?
yeah i'll look into it...good catches with the VT and engine fan diameter
tail drag is high because the tail reynolds number is an order of magnitude above the range i did the fits for. I'll look at getting new fits.
Awesome!
redoing the fits partially solves the problem...drag values are now the right order of magnitude but still a bit high
I think the real problem is why the VT is 470% too heavy...
how is fuselage Cd solved for? We're 112% high on fuse Cd which I think creates a larger actual drag error than the tails
git it to solve without any relaxed constants, TSFC looks fine so i think the drag is pushing fuel burn up
by taking max 777 speed at altitude (I assumed 40K) and scaling the load that would produce back down to sea level i found that the 777 structural sizing speed should be slightly lower than the 737s (3 m/s less)
@1ozturkbe tail drag is now fixed. Fuselage drag seems to be the limiting factor now
We definitely need to run MTFLOW at some point, but I am brutally crushed this week. Would you mind taking care of it? Currently all there is in the model is a Re-based scaling on the CD using fuselage length.
I am removing the Re dependence for now. It is messing things up, and the reason is that the drag is scaling both with wing area increases, and with fuselage length increases, really penalizing us. This will do for the short term, especially since the fuselage Cd is constant for TASOPT anyways. I will try and dig up what it is for the 777 from the docs.
As I suspected, the constant drag coeff for the fuselage fixes 777 wonkiness.
Also, I noticed some odd behavior where there is an untight constraint that has to do with fuselage cross-section for the 777, probably to exploit some structural efficiency in floor/fuselage bending. Will investigate. Reference issue #57 .
HT is still small but as of https://github.com/hoburg/d8/commit/b3c868b0d9125e7f4a0fbab4d02cdbeb88297d06 the 777 is working pretty darn well
so I'm closing for now
@1ozturkbe after fixing a series of drag bugs and improving our drag buildup 737 and D8 work better but 777 is epically failing. This appears to be due to over calculation of drag. can you take a look at it?
I think fixing this should be our top priority
lol disregard issue resolved...had the wrong range in which coupled with some of the TASOPT drag scaling off of areas messed a few things up
@1ozturkbe can you take a look at 777 and see if I'm missing something? right now the final GP solve has relaxed constants