Differences in our SP model and TASOPT

[mayork]

This issue is a running list of modeling differences between our SP model and TASOPT.

Engine

• On/off design point distinction removed in SP model
• Constant gas properties assumed in each component of SP model Note the engine model was successfully validated versus TASOPT

Fuselage

• BLI drag relief factor used while TASOPT uses power balance
• TASOPT fuselage drag determined via pseudo-axisymmetric viscous/inviscid calculation method while SP model uses flat plate with form factor + power law fit for profile drag. -NOTE: TASOPT seems to set the drag coefficient of the fuselage to be constant during all phases of the flight. The GP model now incorporates the same CDfuse, therefore this issue is resolved!

Wing

• SP wing profile drag coefficient determined by Mach number dependent Xfoil fit (TASOPT uses @D airfoil drag database and infinite swept wing theory)
• SP induced drag via parabolic drag model whereas TASOPT uses a discrete vortex Trefftz-Plane analysis
• TASOPT wing discretized into the 3 pieces, includes engine load which we don't
• SP model has approximated fuel volume constraint. SP model does not take into account fuel within the centerbody of the aircraft.
• Wing location and Sh are set by driving pitch trim and stability residuals simultaneously to zero at the design case.... @1ozturkbe I think we may want to implement this
• Oswald efficiency modeled differently

VT

• Same structural model differences as the wing

HT

• Same structural model differences as the wing
• TASOPT discreetly computes the SM for every flight segment (we only enforce a minimum) (shouldn't make a difference in result.)
• We make a neutral point approximation using Drela's Aircraft Rules. TASOPT uses CM stuff to get a similar result.
• We have no tail downwash factor

Nacelle Drag

• TASOPT uses a loaded ring airfoil while SP model assumes the nacelle is a turbulent flat plate

Flight Profile

• TASOPT allows cruise climb, SP model doesn't. Update: SP model DOES!
  • TASOPT includes descent, SP model doesn't
  • TASOPT includes takeoff and cutback, SP model goes straight into a MTOW climb

CG Modeling

• Some component weights and CG locations have been lumped together in SP model to simplify the calculation. Should not affect results significantly.

Iz Modeling

• We model Iz, whereas TASOPT doesn't use it for VT sizing (uses a volume coefficient).

CM Modeling

• TASOPT computes an overall aircraft CM, we do not attempt to do this as of now.
• We assume a constant wing CM

Random Other Things We Don't Compute

• Cp

[mayork]

@1ozturkbe update above with any other differences you know of then we can bring Woody into the loop because I think he's curious about this

[1ozturkbe]

Will do, definitely! Will transfer my list over.

[1ozturkbe]

Updated some of your additions Martin. TASOPT doesn't take into account load relief from distributed fuel load. And structural weight does include skin weight in the form of fwadd.

[1ozturkbe]

Also, when it comes to Cm, I doubt it is going to influence our solution, and it is going to be a major pain in the neck to implement. It should be really low in our list of priorities, but definitely should include in the list.

[1ozturkbe]

Also, we model the z moment of inertia for our VT sizing, whereas TASOPT doesn't... @mayork do you think we should remove the yaw acceleration sizing constraint then?

[mayork]

TASOPT definitely has an option for VT tail sizing that is yaw rate acceleration

[mayork]

it was a new addition in 2.16 tho, so look in that documentation (on the Dropbox) to see how Drela handles Iz

[1ozturkbe]

Regardless, I wasn't able to locate the derivation of the moment of inertia for TASOPT in the documentation of 2.16.

[mayork]

okay lets just take it out then and see what happens

[1ozturkbe]

I mean, if it exists in TASOPT, by all means we should keep it. I am confident that our approximation is within 5% of TASOPT, since the calculation is relatively basic and not prone to error. I just wanted to make sure we are being consistent with the yaw rate constraint.

[mayork]

sounds good...drela actually added it in after that tail sizing study i did

[1ozturkbe]

That's pretty cool.

[1ozturkbe]

Also, the CG constraints are not working... I am exceeding the number of GP iterations and it still isn't solving. I have also formulated the fuel fraction as a posy. constraint, as well as the CG location, and it still doesn't like it...

[1ozturkbe]

I think we are having a similar 'flatness' of the model where it is bouncing around in a region and not really reaching a solution. I am debating now other ways to make the CG work. One idea is this: We could use Signomial equalities to calculate strictly what the CG at the beginning and the end of the mission are, and make use of the fuel weight fraction to make a linear approximation for the CG location during the other phases of the mission.

[mayork]

did you check the costs to see how it's bouncing around? i'm interested to know if the costs are varying a lot or a little

[mayork]

if you push the code to a branch i'd be curious to see how it's bouncing

[1ozturkbe]

One sec, I'm implementing the idea above atm. Give me another 15 mins before I call it a day...

[1ozturkbe]

Ok, I have reached the quota of my patience today. Pushing... I only formulated it for D82.

[mayork]

is it the linear interpolation?

[1ozturkbe]

I commented that part out. If you want to try that as well, it has been commented in the Mission section. Just replace the one set of CG formulation with the other.

[mayork]

so what's the currently implemented CG formulation in the push?

[1ozturkbe]

Btw, I didn't implement the linear interpolation; I just let the CG be free between the lower and upper bounds.

[mayork]

also, how accurate relative to TASOPT is it?

[mayork]

i don't see anything pushed

[1ozturkbe]

Big merge conflicts... Working on it. Also, no clue how accurate this is relative to TASOPT; I don't imagine TASOPT can multiply distances and weights better than we can...

[1ozturkbe]

Finally. Knock yourself out :/

[mayork]

it isn't solving for me lol

[1ozturkbe]

I thought you wanted to see the costs bouncing around. If you want it to run, you have to turn on the constraints in the Mission segment, and turn off the other ones. Even so what ends up happening is that the xCG and xAC coincide during all segments of the flight, which is physically infeasible, but there is no way to enforce o/w without Signomial Equalities that break the problem...

[mayork]

Okay got it! Sorry misunderstood what the push was

[mayork]

yeah that push is bouncing between four different points...the lowest cost solve isn't a good solution

[1ozturkbe]

Actually, how do you pull out the solves if the algorithm doesn't terminate?

[mayork]

you can make a table by doing this

solver_out = m.program.gps[-1].solver_out
m.program.gps[-1]._generate_nula(solver_out)
result = m.program.gps[-1]._compile_result(solver_out)
print result.table(tables=["freevariables", "constants"])

obviously just change the -1 to access the solve you want. i'm not sure this works if you keyboard terminate the solve, but i'm sure it does it max_iter is hit

[mayork]

to get to the one that solves what exactly am I supposed to do? comment out the CG stuff in AircraftP and uncomment the stuff in Mission?

[1ozturkbe]

Yup, should solve then!

[mayork]

odd. it was unknown. I'm just going to revert and to the previous commit and try out forcing the aerodynamic center and CG to be different

[1ozturkbe]

I can push another version that works if you'd like.

[mayork]

using the CG model at commit f50c35baa9d6ae25de the two lines below bring the HT area to within 1.3% without having the tail volume coefficient specified.

        climb['x_{AC}'] >= climb['x_{CG}'] + 7.5*units('ft'),
        cruise['x_{AC}'] >= cruise['x_{CG}'] + 7.5*units('ft'),

The question now is, does this make physical sense? I'm honestly not 100% sure but i think so...we're roughly saying the CG is 7.5' behind the quarter chord which feels reasonable to me

[1ozturkbe]

Wait why don't you make that a function of the chord length then? It seems arbitrary to use 7.5ft actually, and it would be better justified to have it be f(c_{mac}). I'm about to push a new version btw, that works properly.

[mayork]

the 7.5 is 100% arbitrary i was just testing the method to see if it had any effect. will try making if a function of chord in the version you push

[1ozturkbe]

Sweet, I like it. Wait, perhaps we can make the maximum CG shift equal to the CG difference between the beginning and end of flight?

[mayork]

doesn't work as a function of mean chord and I'm also pretty sure it's not physically accurate I was wrong in what I said earlier we're forcing the CG back behind the quarter chord. I think what this has told us though is that we need a method to push the CG and AC apart. Do you think we should just try and calculate the real AC?

[1ozturkbe]

I think that would be the next thing to try... We needed to differentiate the xAC from xwing anyways, and perhaps we have been pushing it off too long. Perhaps we can keep going with the current CG model, formulate an xAC and xNP calculation, and proceed. Good idea.

[mayork]

setting the AC equal to the quarter chord is a no go

[1ozturkbe]

Interesting... I'm assuming you did xAC >= xCG + 1/4*cmac?

[mayork]

yep. wouldn't solve. making it a signomial equality was also unsuccessful.

[mayork]

I'll look at doing a neutral point calculation.

[mayork]

I don't think the neutral point calculation looks too promising....we need to compute dCm/dCl which is pretty damn ugly

[1ozturkbe]

Btw, I don't know if you have noticed @mayork, but the CG constraints actually leave some distance between the XAC and XCG for the 73, but cause them to butt up against each other for the D8, although we enforce some downforce on the HT. Kind of an interesting result considering the different engine locations and how it contributes to the xCG.

[1ozturkbe]

Also, what the hell, for some reason the total weight of the d82 is coming out to be more than the sum of the components? something really weird is going on... tracking down now. Update: Why does the dry weight of the aircraft include the passengers? Utterly confusing to me. Changing now.

[1ozturkbe]

I think the 90% FuelFrac estimate for useable fuel is waaaay too conservative. Where did you get this value? I think this is one of the reasons we are struggling with the TCS warnings (somewhere we are not accounting properly for the fuel in the wings that is unusable.)