D8 Objective Function

[mayork]

Right now the objective function is aircraft['W_{f_{total}}'] + 1e5*aircraft['V_{cabin}']*units('N/m**3') but the problem is if I lower the coefficient on V_cabin the model doesn't converge. My initial understanding was the coefficient simply places a downward pressure on cabin volume, which sounds fine. But, if that's the case, we should be able to place a relatively small constant in front of it and the model should solve (I did this with some of the models in the engine paper). Any idea why we can't lower this coefficient?

[1ozturkbe]

I think I have an idea... my hypothesis is that the order of c*V_cabin has to be larger than the order of W_ftotal, or else the cabin volume will increase because it is structurally more efficient, at the cost of giving an unrealistically large cabin for such an aircraft. We need to have the cost of Vcabin outweigh the fuel cost significantly. Let me test this and comment again here.

[1ozturkbe]

So I ran the model at c = 1000,5000,1e5, 1e6. The results are: 1000: No solve. 5000: Solving took 12 GP solves and 47.5 seconds. Vcabin = 420 m^2. 1e5: Solving took 8 GP solves and 34.4 seconds. Vcabin = 420 m^2. 1e6: No solve. From the results, I think we can infer that a high cost on Vcabin actually causes the cabin dimensions to converge in the earlier solves, reducing the number of total solves. But what the hell with the 1e6 solve? No idea... Maybe at that point the penalty function is overshadowing the actual objective, messing with the gradient values? In either case, I think we should have a way of removing V_cabin from the objective... Best way would be to somehow integrate it into a weight or drag component.

[1ozturkbe]

I think we can agree that having solution behavior that depends on the coefficients in front of unimportant variables is a very unpleasant situation...

[mayork]

What variables do we compute based off of the cabin volume?

[1ozturkbe]

Nothing... It's just to baseline it against TASOPT. Technically we could just make it a SigEq... This is perhaps the best thing to do. I'll do it and make a note.

[1ozturkbe]

Or I could put the buoyancy weight model in, although that makes the model significantly slower, for very little gain. I'll try both.

[1ozturkbe]

This is worse than I thought... The fuselage model blows up if you don't have Vcabin in the objective. It's because Rfuse blows up as well. Poooop!

[1ozturkbe]

What puzzles me is the fact that fuselage drag is a function of wing surface area.... it makes zero sense! You have the same fuselage with a different wing, and you get a different drag, whaaaat?

[mayork]

Or we could just post compute it, I'd rather not add a signomial Equality

[mayork]

And yeah that fuselage drag is odd....is it some data fit drela did?

[mayork]

Nvm can't post compute missed that comment during first read...can we do some sort of skin weight based off of the surface area? That will limit Rfuse and cabin volume

[mayork]

for what it's worth TASOPT sets Rfuse, although I don't think we should.

[1ozturkbe]

About your previous comment, you can't compute skin weight based on surface area, because unfortunately, as surface area goes up, the weight will go down because it becomes more structurally efficient in bending :P

[mayork]

ah...i thought there might be a weight for non-structural skin somewhere

[mayork]

so there's no weight that scales up with volume radius or surface area?

[1ozturkbe]

So the weight of the pressure shell goes with R^2, and the stiffness of the shell goes with R^3, so there is an optimal radius that is larger than the minimal radius. Unfortunately the solution to this would be to have drag be a function of the cabin volume, but that is not the case because Drela makes the fuselage drag coefficient constant (normalized by wing area) to be able to sum the coefficients up to give the overall drag coefficient

[mayork]

i'm thinking this might be an instance where we have to diverge from what Drela does in TASOPT

[bqpd]

Is this the tasopt objective? I bet it'll be better behaved as a product using powers to weight...

On Mar 28, 2017 17:43, "mayork" notifications@github.com wrote:

i'm thinking this might be an instance where we have to diverge from what Drela does in TASOPT

— 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/41#issuecomment-289810884, or mute the thread https://github.com/notifications/unsubscribe-auth/ABagGJHVStFQwiY0fwTkCjGDaSZRr7N8ks5rqSlkgaJpZM4MqqYa .

[mayork]

not it isn't the TASOPT objective, TAOSPT is just fuel burn. good idea using weights, @1ozturkbe try to implement that

[mayork]

@1ozturkbe any updates here?

[mayork]

I really think this needs to go...experimenting with diff objective functions now and the factor in front of the cabin volume makes a difference. This is downright sketchy

[1ozturkbe]

Well it simply will not work otherwise. And since we are implementing Drela's fuselage drag model verbatim, there is no way to put downward pressure on the cabin volume, other than by bringing back the buoyancy weight constraints, which kind of mess up the cruise climb calculations. Definitely would not recommend this.

[1ozturkbe]

Let me mess with bringing the buoyancy weight back. Perhaps I can do this in a way that will not break cruise climb. I have some ideas.

[1ozturkbe]

This is not working, at all. Even with buoyancy weight added the aircraft seems to think that it is better to have a long fuselage, and picks this option although it would seem clearly suboptimal for an engineer. When math violates engineering intuition...

[mayork]

Can we not just post compute the cabin volume?

[mayork]

What exactly does the cabin volume in turn determine?

[1ozturkbe]

You can post compute, but it's not just cabin volume that is problematic. It's also lfuse and Rfuse and dRfuse, they would all like to blow up. It's just that lfuse blows up first so that we can have smaller tails (I believe, not 100% sure why).

On Wed, Apr 12, 2017, 05:46 mayork notifications@github.com wrote:

What exactly does the cabin volume in turn determine?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hoburg/d8/issues/41#issuecomment-293527784, or mute the thread https://github.com/notifications/unsubscribe-auth/AO9SX-k15TC7d6zLWHi_V2WbaMngS3kdks5rvJ2KgaJpZM4MqqYa .

[1ozturkbe]

I have gotten the code to run with Wbuoy, but now I have the \pi_{d} relaxed. Will post updates here.

[mayork]

okay well TASOPT sets the fuselage radius. That could be an option that solves this problem, correct?

[mayork]

also, can we not fudge the drag to have a cross sectional area term?

[1ozturkbe]

But then we are going to be off on fuselage drag when we sweep... we can't just patch this, we have to think about a method that will not break when we are doing analysis. Also, you would need some huge pressure on the drag term to achieve tightness.

[1ozturkbe]

The radius constraints are already tight, it's the length that is not, even with SigEqs. (and plus, there already is a substitutions for R, in D8.2, I checked just now).

[mayork]

can we just make a new fuselage drag model?

and isn't the length set by the number of passengers?

[1ozturkbe]

That's what I was thinking of doing. Just setting l_{fuse} as a f'n of the number of seats, and making nose and tail cone lengths as a f'n of the seats as well. We will be off on some fuselage weights, but should be a no-issue. (and still there is no guarantee of tightness, since nseat >= npax)

[mayork]

what sets the length right now?

[1ozturkbe]

Adding drag penalty to linear to length (which is higher than what would be predicted by a turbulent flat plate model) doesn't put sufficient pressure on fuselage drag to make length tight.

[1ozturkbe]

Length is set by the number of seats, plus some tail and nose cone lengths which are either substituted or set by taper ratios.

[1ozturkbe]

We can do this... The whole problem is that nseat >= npax. What we can say is that nseat == n_pax[0], the first component of the multimission. Then we can set npax to whatever we would like, and set fuselage length as a fn. of nseat! I will implement this now.

[1ozturkbe]

Woooo, it worked! Pushing soon! (sorry about the wait, longer than expected.)

[mayork]

Excellent!

[1ozturkbe]

Also, putting drag penalty as a function of lfuse significantly speeds up solution time (35 vs 115s, my computer is slow today)! I might just leave it in there.

[bqpd]

(this is a super interesting result! cc/ @whoburg)

[1ozturkbe]

Just pushed. A small note, I made a pessimistic approx. for Wbuoy since when I add the proper SP, the code returns UNKNOWN. Will figure out why eventually, but for now I will leave it in its current 'robust' formulation.

[1ozturkbe]

also @mayork, \pi_{d} is relaxed for d8.2 still. Are we certain this doesn't have to do with satisfying p_drop?

[mayork]

i already debugged this it's the VT engine diameter constraint...i guess you didn't edit that yet?

[mayork]

closing

[whoburg]

So did we get fuselage volume out of the objective? I just read through this thread and I'm a bit confused. It seems to me there are two possible cases

• tasopt validation, where it makes sense to just set the cabin radius and volume, if that's what tasopt does

• design studies beyond tasopt validation, where cabin volume should be optimized, and clearly we need aerodynamics and structural models to do so

[mayork]

Yep it's removed the objective, non-issue now

[mayork]

From the* (don't know how to edit on phone)