Closed mayork closed 7 years ago
No, it isn't sized for anything in cruise. The fuselage only has a set of max load cases, and its only performance parameters have to do with drag.
Are you asking this because the engine is still creating issues?
yep. last night i was able to integrate the engine into everything except the breguet range and steady level flight constraints. I'm not entirely sure what the issue is when I integrate with those since they're the same constraints I use in the engine/flight profile/simple aircraft model.
Interesting... The only reason I'd see any reason for worry is the fact that T_e (engine out thrust) is sized by the climb-out thrust of the engines. But that seems to work fine. Perhaps it could have been with the use of Nsplit? You've probably checked this already though. Another issue might have to do with whether or not cruise-climb is allowed? I'm just spitballing here.
I don't think it's Nsplit, i've printed the constraint out and the vector indexes appear correct.
I considered cruise-climb, but don't see a reason this formulation shouldn't work since it already has elsewhere. I plan on looking into this more.
i think that the horizontal tail volume is going to zero
Why would it do that, when it was perfectly fine without the engine?
can't say for sure. this is certainly adding an extra degree of freedom. Right now the most I can say is that there appears to be a relation between what I set the min allowed HT volume coeff to and the min allowed cruise thrust. Working on getting more detail now.
Btw also, why did you change the basic engine model in D8_integration? We need it to run CFP.
oh whoops...didn't realize you were still running CFP. You can uncomment the lines and i'll make an untracked file.
I edited the file because the comment out parts are integrated to the real engine model.
the last push converges. cruise thrust limited to 37000 N and tail volume limited to 0.05. What are your thoughts on removing the HT and seeing if everything else integrates then adding the HT back in? I think this could all go back to that min static margin constraint
(Btw I'm assuming you lower-bounded both the thrust and the volume coefficient here). I don't think that is necessary or useful at this point. The horizontal tail behaves as expected in CFP, and removing it would just revert us to having subs for CG and AC, which really dumbs down the aircraft superclass. I think the approach should be to incrementally unbound the troublesome variables instead. I also think it is worth doing some sweeps on the integrated model, because it doesn't make too much sense that the HT breaks with the engine, but does fine without it. I think the failure is more nuanced than that, and we need to figure out when exactly the model breaks.
alright, but i don't know how to integrate the engine fully without removing the tail. I'm not sure what engine-tail interaction is causing the issue, and the only way I can think of is to remove the tail, integrate the engine, and then piece by piece add in the tail. Do you have another idea on how to do this?
Well firstly, I had changed the cmw value to 0.1 in the old model, but it has reverted to 1 in engine_integration. That is why the HT is so small.
With that new value, the HT should be just fine.
And, other than the vertical tail span constraint (greater than 4*engine radius), there is no constraint that explicitly links the engine to the tail. Therefore, I suggest running a sweep of the cruise thrust until the model fails, and then trying to decipher what is going on by plotting the data. I do not think the model is failing because there is a non-sensical constraint. Also, isn't a cruise thrust of 37000N per engine really high? (Nvm, it seems to be fine). Perhaps we can't generate enough drag :P You may try to relax the drag constraint to thrust >= drag.
I can run a series of engine parameter sweeps with the working CFP, and see if it makes a difference. Btw, you may also want to check the substitutions within D8_engine_integration and see if they match CFP. I have tried to be diligent about moving all of the subs into the dictionary at the end of the document, but there are a few in Aircraft and AircraftP because of the duplicate variable name issues, and the difficulty in declaring vector substitutions in a non-messy way :/.
Also, I have been doing through TASOPT again to make sure that there were not glaring sizing constraints that were missing... immediately found two issues that seem quite important. One is the fact that engine and apu weights significantly affect bending moment. The other is that the aircraft has positive buoyancy weight at altitude. Will fix and push on CFP; should not affect the model results drastically.
doest tasopt account for the positive buoyancy weight?
Yes it does. I will dig up in the runfiles to see what default cabin pressure TASOPT uses. Update: TASOPT runs use a default pressure altitude of 8000ft, which is 10.91 psi. This is slightly tricky to implement, because below this altitude, the aircraft will obviously have zero buoyancy weight. I expect you will not have huge errors if you don't implement buoyancy altitude for the climb segments, but I'll see how I can make this work. Actually, it seems fine, because the climb segments peak out above this altitude. I'll just assume it is 0 at takeoff, and calculate it using a signomial inequality at all other segments.
I want your opinion on something @mayork. It seems tricky to integrate the buoyancy weight into the W_start - W_end scheme in Mission. Do you have any objection to adding it as such:
W_avg >= (W_start * W_end)**0.5 + W_buoy
It might be cleaner, since then we don't have to turn a bunch of monomial equalities in Mission into posynomial inequalities, and we know that the difference in W_start and W_end is only a function of fuel burn, and not also altitude change. The only issue is that W_avg isn't going to be a strict geometric average now of the segment beginning and end weights. Lmk what you think. (also, to keep in mind, the buoyancy weight is only on the order of 300 lbs).
For it to be a valid constraint the + would have to be * and I'm not sure
W_avg >= (W_start * W_end * W_buoy)**0.5
makes sense. The way it's written W_buoy should be a negative value, correct?
I updated... Sorry about the hasty, typo filled message lol.
no worries, i think my comments still stand
No, the following would be a terrible approximation:
W_avg >= (W_start * W_end * W_buoy)**.33
Since W_buoy is a totally different order of magnitude, the approx. would be waaay off. You'd have to add it at the end. It doesn't even make sense, because it would be as such:
W_avg >= ((W_start + W_buoy) * (W_end + W_buoy))**.5
which is pretty much what the previous equation is. Nvm, I am going to use the formulation just above.
sure but
W_avg >= (W_start + W_end + W_buoy)**0.5
isn't a valid constraint. You can't have variables added together and then raise to a power
I told you it was a typo... check what I actually wrote
oh sorry...the message didn't' update on my screen. just refreshed and got the updated one.
W_avg >= ((W_start + W_buoy) * (W_end + W_buoy))**.5
is also not valid
I mean this one:
W_avg >= (W_start * W_end)**0.5 + W_buoy
Doing this over chat is hard.
okay that makes sense. the only thing i don't get now is the sign on W_buoy...shouldn't the buoyant force be acting in the direction of lift and thereby decreasing the average weight
No. The air is denser on the inside, therefore you have an inverted helium balloon :P. Update: buoyancy weight integrated as SigEq. Will need to relax later. Now looking at D8_engine_integration, and comparing to CFP.
Upon first glance, haven't found any significant differences between CFP and D8_engine integration. Though I am confused about one thing. You include engine within both cruise and climbP, but not in aircraftP, unlike the other performance models. Why is that? Could that be the reason for the error?
it's just due to the architecture of the engine model, it was a conscious decision
Cool; best of luck with the reintegration, and let me know if I can help you with anything. Let's definitely meet tomorrow to discuss.
the problem appears to not be the state linking
Btw, of course the cruise altitude of the aircraft is going to be constant! Because we had CruiseAlt as a variable, it is necessarily true that both cruise segments happen at the same altitude.
i adjusted that in the one where cruise climb is allowed
K cool, I thought I had had a eureka moment :P
For some reason, I can't resolve the discrepancy of between the 'thrust' of oldengine and 'F' of engine during climb... Just can't set them equal. Any ideas? It doesn't look like 'thrust' has any subs or constraints other than the 2*max cruise thrust constraint.
that's the issue i've been battling. Not sure what the problem is.
Well it seems pretty critical. I will beat my head against it for a bit.
I have found the solution to our problems. We just need to get rid of oldengine altogether. Just have some placeholder variables instead. Some seriously weird shit is going on with oldengine that makes zero sense. Will do this now.
let me know if it works
This is the most vexing issue I have ever seen... still not working.
I've almost got the HT integrated ithink
engine is now integrated, closing
@1ozturkbe i've gotten the engine integrated everywhere except in the cruise breguet range and steady level flight constraints.
Is anything in the aircraft sized for cruise? I can't think of anything but don't know much about the fuselage.