Aerodynamics queries

[seanmcleod]

@Octal450 do you have a list of the sources you used to build the aerodynamic model?

How come you're using density altitude to vary the Cl vs Alpha curve? Shouldn't you be using Mach instead?

https://github.com/legoboyvdlp/A320-family/blob/afc6db9d236f5211039a70e5b50e6cb7f1cdf104/FDE/Config/a320-aerodynamics.xml#L54-L87

In terms of the drag modelling I'm curious why you've used both drag due to alpha and drag due to Cl squared. Typically I'd expect to see one of the other used.

[Octal450]

Technically the "official" discussion place is the forum or Discord. Not really an issue so I'll close it, but I will happily discuss with you. :)

These curves are based on several NASA documents about airliner wing aerodynamics, which are shaped by me to match known data I collected about this wing.

Yes, compressibility effects have a factor, but I found the thinner air at altitude based on the data I collected. So currently I haven't yet modelled compressibility effects because I don't have enough data on it's effects on airliner wings, but I do have coffin corner effects due to thinner atmosphere.

Hence the two curves.

CDalpha and CDi serve two different purposes. One models the change in drag due to AoA at any configuration, which is currently modelled as a symmetric curve. CDi models the change in drag due to all so yes, alpha - but also flap, delta lift from surfaces, etc, proportionally to the change in total lift. Then you see additional "additions" to CD which are irregardless of alpha or total CL, and are the "basic" drag additions for flap, surfaces, etc.

I am not fantastic at explaining this but hopefully that made sense?

Let me know if any more questions

Bests, Josh

[seanmcleod]

Yep, I didn't see a Discussions option for this repo, and neither the bug report nor feature request really made sense either, so went with other. Didn't realise there was a separate forum and Discord for this.

[Octal450]

All good!!! Did I answered your question?

Bests, Josh

[seanmcleod]

Yep, thanks for the reply.

In terms of the Cl vs alpha this is what you currently have, with interpolation from the green line to the purple line as altitude varies from sea-level to 45,000ft.

I still think you're using the wrong variable, i.e. density altitude, for this. I'm pretty sure the effect you're trying to achieve is really the Mach/compressibility effect, and so you should be using Mach rather than density altitude.

You can see with your purple line you've got a slightly steeper slope and the lower max Cl at a lower alpha, pretty much matching the Mach effect.

In terms of changing Cl vs alpha curves, here are some examples from some Boeing documentation for a 737 simulator. You'll notice that they have a low speed set, with a line for each flap (DFEF) config.

And then they have a high-speed set.

With:

Lastly, none of the CL functions depend on altitude:

Hence my surprise with your choice of altitude 😉

[Octal450]

I see what you mean, thanks. I hadn't come across this detailed data before.

I will do some work on this soon and see what I find.

Kind Regards, Josh

[Octal450]

It looks like the range between Vmin and Vmax isn't too big at 40k. Looks like about 0.1 mach + change which could explain why altitude "appeared" in the data. So I'll do some tests with varying CLalpha by mach and see the result.

Kind Regards, Josh

[Octal450]

@seanmcleod You were 100% correct. I did data fitting and it turns out at altitude the data match very nearly to what I had before to mach.

But the behavior would obviously be effected throughout other flight regime.

Later I will go back and tweak the curves, but for now will fix this.

Many thanks for pointing that out!

Kind Regards, Josh

[seanmcleod]

No problem.

So you could set your green curve as the Mach 0.2 entry and the purple curve as say the Mach 0.8 entry as a quick fix.

Longer term you could add say a Mach 0.4 and 0.6 curve with different slopes and different Cl-max values.

I noticed that you already adjust the protection trigger based on Mach. So once you update the Cl vs alpha curves to change based on Mach you'll be completely in sync. Obviously double-checking that the Cl-max for each of the Mach specific curves is a couple of degrees greater than the protection values you have below.

https://github.com/legoboyvdlp/A320-family/blob/5c68a4e59256864ebff61c373a03e6e245a36670/Systems/a320-fbw.xml#L93-L111

Also, longer term you may want to update your Cl vs alpha curves to include entries for each flap configuration, like you see in the 737 low speed example I posted above. Since this would allow you to have a different alpha for each flap configuration's max Cl. At the moment, the following simple delta approach shown below, which is common to most JSBSim FDMs, means the stall angle remains at the same alpha, you're just pushing your green and purple curves up, without changing where the peak is.

https://github.com/legoboyvdlp/A320-family/blob/5c68a4e59256864ebff61c373a03e6e245a36670/FDE/Config/a320-aerodynamics.xml#L111-L128

[Octal450]

Hi, Already done. :) I found when fitting data and running simulation that 0.9 produced the expected.

Re delta, I'm aware of this yes. Improvements ate planned but not yet implemented.

All though I should point out there seems to be some Disconnect. I see values in some tables like 25 30 deg AoA for peak CL which is wrong.

Kind Regards, Josh

[seanmcleod]

Which tables are you referring to in terms of 25, 30 deg AoA for peak CL?

[Octal450]

It was some local PDFs, I'm recalling. Your 737 shows about 20. For A320 and MDs, thats still high, but maybe for 737 it's right.

Also I wonder if that data Alpha where fuselage long line is 0 or if it it's like alpha where chord line is 0.

Kind Regards, Josh

[seanmcleod]

Now in terms of the drag modelling.

As I mentioned, I was surprised by the combination of CD-alpha, CD-i plus additions for flap settings. Typically you'll see one or the other.

One issue with the $C{L}^2$ approach is that it doesn't work past $C{L_{max}}$ since the decrease in $CL$ after $C{L_{max}}$ means you end up with reduced drag when you pass the stall!

In the Boeing simulator data, like in the $C_L$ vs alpha case, they have a set of curves defined for each flap configuration for the low speed environment, and then another set for high speed based on Mach. Note that in the drag case they plot alpha on the y-axis.

I wrote some code to plot your drag setup, here is a copy for you to double-check and/or run it yourself.

import matplotlib.pyplot as plt
import numpy as np

def CLalpha(alpha, flap):
    alphas = [ -9.8475, -2.0912, -0.0098, 2.2280, 4.2779, 6.4218, 8.4561, 9.2699, 10.7094, 11.6170, 12.6496, 13.7292, 14.7930 ]
    CLs = [ -0.5652, 0.0625, 0.2386, 0.4260, 0.5779, 0.7540, 0.9163, 0.9842, 1.0843, 1.1538, 1.2184, 1.2911, 1.3444 ]

    flap_delta = 0
    if flap == 10:
        flap_delta = 0.0923
    elif flap == 20:
        flap_delta = 0.2079
    elif flap == 40:
        flap_delta = 0.4207

    return np.interp(alpha, alphas, CLs) + flap_delta

def CDalpha(alpha):
    alphas = [ -14.7960, -12.2922, -9.4900, -6.9768, -3.2108, 0, 3.2108, 6.9768, 9.4900, 12.2922, 14.7960 ]
    CDs = [ 0.0549, 0.0512, 0.0379, 0.0224, 0.0049, 0, 0.0049, 0.0244, 0.0379, 0.0512, 0.0549 ]
    CD0 = 0.016 

    return CD0 + np.interp(alpha, alphas, CDs)

def CDiCL(CL):
    return 0.0384 * CL**2

def CDflap(flap):
    return flap * 0.00122

#########
alphas = []
CDs = []

lift = {}
lift[0] = []
lift[10] = []
lift[20] = []
lift[40] = []

drag = {}
drag[0] = [ [], [] ]
drag[10] = [ [], [] ]
drag[20] = [ [], [] ]
drag[40] = [ [], [] ]

for alpha in np.arange(-9, 14.1, 0.1):
    alphas.append(alpha)
    CD = CDalpha(alpha)

    CDs.append(CD)

    for flap in [0, 10, 20, 40]:
        CL = CLalpha(alpha, flap)
        CDi = CDiCL(CL)
        CDtotal = CD + CDi + CDflap(flap)

        lift[flap].append(CL)
        drag[flap][0].append(CDi)
        drag[flap][1].append(CDtotal)

# Plot CL-alpha curves
plt.figure()
for flap in [0, 10, 20, 40]:
    plt.plot(alphas, lift[flap], label=f'CL-{flap}')
plt.legend()

# Plot drag curves
for plot in ['CDis', 'CDtotals']:
    plt.figure()

    plt.plot(CDs, alphas, linestyle='dashed', label="CD0 + CD_alpha")

    for flap in [0, 10, 20, 40]:
        if plot == 'CDis':
            plt.plot(drag[flap][0], alphas, label=f'CDi-{flap}')
        if plot == 'CDtotals':
            plt.plot(drag[flap][1], alphas, label=f'CDtotal-{flap}')

    plt.legend()    

plt.show()

print('Done')

First off, double-checking the $C{L{\alpha}}$ curves for the clean configuration and 3 different flap settings, since the $C_L$ values will be used to calculate CD-i. Compared to the Boeing low speed $C_L$ vs alpha curves, these look like they're a fair bit lower.

A bit of a diversion from drag, but in terms of the $C_L$ values being a fair bit lower than the Boeing equivalents, there is also some useful data for an Airbus A330 in full landing configuration with input from Airbus - https://w3.onera.fr/smac/sites/default/files/2024-01/CALC_v2.pdf.

They list $C_{L0}$ as 0.9 and $C{L_\alpha}$ as 5.5 which is in the same ballpark as the Boeing data for their some of their larger flap settings, but also quite a bit larger than your $C_L$ curve for max flap setting.

Now taking a look at your CD-alpha and CD-i curves. I've also plotted alpha on the Y-axis to match the Boeing data.

And finally the total CD curves for the different flap configurations.

The drag for the maximum flap setting in particular is a lot lower than the Boeing data.

My suggestion would be to replace your current CD0, CD-alpha and CD-i data with a single CD-alpha table that basically matches your current CDtotal-0 curve, the CD-flap entry you currently have would then be added to that if flaps are selected. May want to look at making the CD-flap non-linear so that for maximum flap deflection you get closer to the Boeing data for their maximum flap deflection.

The other suggestion would be to create custom curves for each flap configuration, i.e. like Boeing do, in which case if you went with that option then you would also get rid of your current CD-flap entry.

Talking of high speed Mach effects on drag, here is the Boeing data.

Compared to the data you have for Mach effect on drag. You have no Mach effect on drag at all, all the way up to Mach 0.82, and only starting to kick in after 0.82? Would appear to be way off compared to the Boeing data.

https://github.com/legoboyvdlp/A320-family/blob/5c68a4e59256864ebff61c373a03e6e245a36670/FDE/Config/a320-aerodynamics.xml#L300-L314

[Octal450]

Hi, Yes. Firstly I should mention that my first goal with the FDE is to match noted parameter performance. Currently, it does do this fairly well within the normal flight envelope. Outside of that, I am already aware of several issues like CL2 that you mentioned which will be addressed in the future.

The reason for CD0 and CDi is due to how I model the drag. CD0 + CDi is the basic drag moment assuming faired surfaces and 0 alpha. The weighing between CD0 and CDi allows me to set the drag correctly for various areas of the envelope, of cruise and approach, etc. CDalpha is the delta drag due to angle of attack on top of this. Yes you are absolutely correct about the effects during Stall, and my CDalpha table does not take this into account. This will be addressed in the future.

Now yes, I could combine everything into a CDalpha table only, but at the cost of tuning and maintenance. Now I can't speak on your observation on coefficient comparision between Boeing and here, as I am sure you are aware, there are many factors on how the coefficients are applied such as what they're multiplied by etc that effect the numbers. Currently the model does deliver fairly accurate drag performance with or without engines running and thus I must admit I'm not too worried about the total drag coeff's being "lower".

Re CDmach, yes, I know. I experimented with this but found when enabling it, I could not match POH data. Drag was too high at high mach, and too low at low mach, after a short bit, I gave up, and used it only to model the high end supersonic drag effects. The rest of the drag by speed changes is supplied by CD0 + CDi by qbar. Yes, it's not optimal, , and I plan to revisit in the future, but the number 1 goal in this is to match expected POH and observed flight data.

I should add for context, that The c172 team took several numbers of "observed" or documented data and implemented it into their flight model, but as someone who has flown real c172s, the flight model is very inaccurate - and I am not the only pilot to observe this. For reasons that I am not really aware of, simply inserting data doesn't really seem to work very well unless you are 100% sure you've accounted for every single factor to compute it exactly like how that data is derived from.

Btw, I really do appreciate your insight and comments. I am by no means a professional flight modeller, I'm actually studying Electrical Engineering. So this is a hobby for me and I'm learning all the time. The comments you've made will definitely help me as I iterate and continue improving my flight model.

PS: I've noticed not all airplanes slew stall AoA with flaps. For example:

Very similar. All though this says 20 degish for CLmax, which is not correct, so I don't actually know what the variance here is. Clean config shows expected.

Kind Regards, Josh

[seanmcleod]

I am by no means a professional flight modeller, I'm actually studying Electrical Engineering. So this is a hobby for me and I'm learning all the time.

Nor am I, so I'm also doing this mostly as a hobby, with some 😉

I'm a software developer, with very minimal hardware development experience, with 90% of my work in the aviation field, e.g. EasyCockpit - https://apps.apple.com/us/app/easycockpit/id542957397 and then a large chunk of work over the years for a test pilot school developing FTI systems and a VSS (Variable Stability System) simulator for them. For example, this was my first FTI system I developed for the test pilot school - https://seanmcleod.github.io/2008/06/geeks-and-fast-jets/

Most of my experience in terms of flight models has been based on my VSS simulator development work in terms of needing to look at and understand the flight model.

my first goal with the FDE is to match noted parameter performance.

No problem with that. I'm just suggesting that you could still do that but in a way that is less confusing.

CD0 + CDi is the basic drag moment assuming faired surfaces and 0 alpha.

However, CD0 is the drag coefficient (for drag force, not moment) when CL = 0, i.e. zero lift, which for most aircraft isn't when alpha = 0. Plus it varies for each flap configuration, so for example for flap configuration 1 CD0 might be at -3 AoA and for flap configuration 2 it might be at -5 AoA.

So for example, you could take the CDtotal-0 through CDtotal-40 curves I generated from your current data and enter those, removing the existing CD0, CD-i, CD-alpha and CD-flap tables/formulas and you would have the exact same performance you have today.

Then later on if you needed to tweak the drag based on some additional performance data, say for example for the full flap landing configuration, you would just tweak the CDtotal-40 curve, and not have to modify CD0, CD-i, CD-alpha and CD-flap to try and achieve the same effect without disturbing some of the other flap configurations etc. Just seems easier to me, and less confusing for others based on the standard understanding of CD0, CD-i etc.

I noticed that the A320 in the JSBSim repo takes this approach for both CL and CD.

...between Boeing and here, as I am sure you are aware, there are many factors on how the coefficients are applied such as what they're multiplied by etc that effect the numbers.

In terms of the Boeing data the only multiplication factor applied for the basic drag is a blend factor between low speed and high speed. A whole bunch of additional drag deltas are then added for things like gear, elevator etc.

I'm not suggesting that you need to exactly match the Boeing data, just more that some of the large variances for some parts may be a red flag/hint that there may be some inaccuracies with some of your data.

You mention matching POH data and other performance data. Do you have that data included in the repo somewhere?

In an ideal world you'd have performance data say for a number of trim points for all the flap configurations which include (alpha, IAS, weight, thrust, control positions). If you don't for example have the thrust then say for cases where your CD may be way too low, then you could be ending up with unrealistically low thrust values in the sim.

P.S My father was an airforce pilot and then an airline pilot, including flying the A320. At the time children were allowed in the cockpit, so I spent a fair bit of time in the cockpit, but unfortunately didn't take trim data 😉

Example of some partial data, can work out AoA to be ~5.5 deg, the A320 can display a velocity vector, but it's often not enabled, but here we can see they're on, and assumed 3 deg ILS glideslope with a pitch attitude of ~2.5 deg, full flap configuration. But we're missing current weight, thrust etc.

[Octal450]

Hi, Nice stuff :)

for drag force, not moment

Oops. Typo. Of course that is correct... I've been very busy so my replies are a little rushed so you may see other similar mistakes.

which for most aircraft isn't when alpha = 0.

I badly explained this. What I meant was I work out the required drag without direct effects of drag from alpha (aka, when CDalpha is no effect). So, this is exactly as you said the drag effect due to qbar, and the drag effect due to qbar * CL2. After this, then I applied CDalpha table. Hope this makes more sense?

Can you explain more about how you compiled the graph directly to account for all situations? Cause for example, CL2 varies by many things, flap setting, alpha, q, etc... so if you no longer have CL2 as an input source, how does the correct? The high speed/low speed balance was created by specifically using the fact that different weighing.

red flag/hint that there may be some inaccuracies

True. But I find it hard to believe that the performance would be correct with a large difference in total drag? Unless I misunderstood you. Seems to be some factor. I have multiplication by Sw a lot, maybe it's that, I don't know.

you could be ending up with unrealistically low thrust values in the sim

Yes it's a balancing act and very annoying to deal with. I certainly don't have ALL enough information. But I've gotten pretty close.

The A320 does only display the FPV vector (showing track angle vs heading and FPA vs pitch) if the button is pushed on the FCP. Most pilot not use it unless they specifically need TRACK or FPA modes of the AP.

Bests, Josh

[seanmcleod]

Hope this makes more sense?

Not yet 😉

drag without direct effects of drag from alpha (aka, when CDalpha is no effect)

$C{D{\alpha}}$ plotted on a graph like the Boeing examples above, or listed in a table always has an effect in that it's never 0. For example, visualize an aircraft model in a wind tunnel, setup with some flap configuration (including 0 flaps), which then gets rotated through from say -10 deg AoA to +20 deg AoA, say at 1 deg increments. At each AoA the drag is measured and the $C_D$ calculated and stored in a table/graph. You then end up with a graph like the Boeing examples above. There is no AoA where the drag is 0.

Now you could have a separate graph for each flap configuration like Boeing have above, which allows you to capture small variations between flap configurations that can't be captured by a simple delta flap increment, or you can go with a delta flap increment if you don't have the detailed data and/or the small differences aren't required for the particular simulator.

Can you explain more about how you compiled the graph directly to account for all situations? Cause for example, CL2 varies by many things, flap setting, alpha, q, etc... so if you no longer have CL2 as an input source, how does the correct?

Sure, although I did supply the complete source code so you could double-check 😉

So, in the code I take your $C_L$ vs $\alpha$ data plus the flap increment you have for $CL$ to generate the CL-0, CL-10, CL-20, CL-40 curves, shown in the plots. So, this takes into account flap setting and alpha. So smaller components like $C{L_{q}}$, aren't included.

Note that in the Boeing model, there is no drag modelled due to q (pitch rate), and also no drag based on $C_L$.

But there is a drag increment for the horizontal stabilizer, elevator, gear etc. Which brings up another point. Since you are changing the lift due to those as well in the calculation of $C_L$ and you have them entered as drag increments in the drag axis as well, it means you're potentially double-counting their drag contributions, or you're having to split the drag contribution into different parts for each, which is just way more complicated and confusing in my opinion. And again, it's not the way I typically see it done, nor is that sort of split/accounting done in the Boeing model.

Being pedantic, CD0 isn't the Minimum Drag necessarily, it can be in some cases, but not always. By definition it's the drag at zero lift, i.e. when CL = 0.

https://github.com/legoboyvdlp/A320-family/blob/5c68a4e59256864ebff61c373a03e6e245a36670/FDE/Config/a320-aerodynamics.xml#L256-L257

So for example in the plots below you can see that the minimum drag (blue dot) is smaller than CD0, which is the point where CL = 0, i.e. where the line hits the x-axis. So for this particular example zero lift occurs at an AoA of -4 deg, and the minimum drag and an AoA of +2 deg.

Here is another example showing the difference between CD0 and CDmin, and how the formula changes from $KC_L^2$ to $K(CL - C{L_{mindrag}})^2$ when CD0 != CDmin.

[Octal450]

Thanks for the info. It'll take me some time to analyze and try to update my computation methods for this, but I'm going to see if I can do that.

Also I see your point about the double add, but in the computation method I use this is intentional, as the total lift to drag vs deflection to drag are items I separately compute.

I definitely see how your approach makes sense. But this would be a pretty big change in figuring it out computation wise on my end. It's much easier for me to compute the components separately. I do see your point about Minimum-drag though, I guess I'll edit that description.

Kind Regards, Josh

[seanmcleod]

In terms of some of the double adding accounting complications, take this example with regards to ice.

So, let's assume the A320 is flying at an AoA of 5 deg and trimmed, and let's assume all the control surface deflections, flaps etc. are 0.

So with no ice we have:

CL = 0.6372 CD0 = 0.016 CD-i = 0.0156 CD-alpha = 0.0142

So total drag coefficient = 0.0458

Now let's assume the aircraft flies into icing conditions and picks up ice on both wings evenly. So, using ice\wing = 1.0.

So in the lift axis that means CL reduces by -0.15 2, and in the drag axis CD increases by 0.005 2, so we have:

CL = 0.6372 - 0.30 = 0.3372 CD0 = 0.016 CD-i = 0.0044 CD-alpha = 0.0142 CD-ice = 0.01

So total drag coefficient = 0.0446

So in effect your current model results in the drag reducing with the addition of ice?

[Octal450]

icing is a placeholder iirc. I actually didn't touch that coeff. It's the one I didn't do.

Will need to look into this

Regds,

-- Josh Davidson

---

From: Sean McLeod @.> Sent: Saturday, October 12, 2024 10:07:05 AM To: legoboyvdlp/A320-family @.> Cc: Josh Davidson @.>; Assign @.> Subject: Re: [legoboyvdlp/A320-family] Aerodynamics queries (Issue #343)

In terms of some of the double adding accounting complications, take this example with regards to ice.

So, let's assume the A320 is flying at an AoA of 5 deg and trimmed, and let's assume all the control surface deflections, flaps etc. are 0.

So with no ice we have:

CL = 0.6372 CD0 = 0.016 CD-i = 0.0156 CD-alpha = 0.0142

So total drag coefficient = 0.0458

Now let's assume the aircraft flies into icing conditions and picks up ice on both wings evenly. So, using ice\wing = 1.0.

So in the lift axis that means CL reduces by -0.15 2, and in the drag axis CD increases by 0.005 2, so we have:

CL = 0.6372 - 0.30 = 0.3372 CD0 = 0.016 CD-i = 0.0044 CD-alpha = 0.0142 CD-ice = 0.01

So total drag coefficient = 0.0446

So in effect your current model results in the drag reducing with the addition of ice?

— Reply to this email directly, view it on GitHubhttps://github.com/legoboyvdlp/A320-family/issues/343#issuecomment-2408595254, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGDJVDEUMOGIGBSL46M2XNTZ3E3JTAVCNFSM6AAAAABPGMNRTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGU4TKMRVGQ. You are receiving this because you were assigned.Message ID: @.***>

[seanmcleod]

So let's say for example you found some source stating that the CD increment for icing for an airliner or A320 in particular is 0.01, i.e. the value you currently have in the drag axis.

But now, because it causes a decrease in CL in the lift axis and since you're using CL^2 as part of your drag calculation, it now means you need to go and increase the published CD ice increment value that you place in the drag axis to compensate for the reduced drag from the decreasing CL.

[Octal450]

please note, I didn't do any work on this yet.

It's a leftover from the old FDE.

Best, Josh

[seanmcleod]

Sure, but the same logic applies in terms of the multiple accounting of drag between the lift axis and the drag axis, whether you've spent the time yet or not to try and tweak it. My point is just how messy and complicated it gets doing the drag this way.

[Octal450]

Yeah I see your point. But I need to be able to calculate the basics first before I worry about that.

J

[seanmcleod]

Sure, no rush or pressure, just trying to suggest an overall simpler approach to drag 😉

The example with the icing above will also apply to a number of the other lift components, e.g. elevator, horizontal stabilizer etc.

[Octal450]

Yeah, I appreciate it, don't worry!

So the thing is, I develop all my planes together. So I need to be able to reproduce (recalculate) results before I implement them. If I can't calculate it, I can't maintain it.

So step one is getting my FDE development tools to produce such a curve and then doing verification that the flight performance is correct.

This may take some time, I am not working on the FDE at this moment, have other things to work on before I get back to it.

Kind Regards, Josh

[seanmcleod]

Last comment on the drag calculation 😉

So using the ice example again, let's say that the drag increment due to ice has come from some reputable source and it's 0.01, and let's assume the negative increment for CL due to ice is also accurate. Now as shown in the example above for 5 deg AoA that actually results in an overall decrease in the drag coefficient of 0.0012.

So to make things balance you decide to take the published drag increment value of 0.01 and increase it to 0.0212 so that the net drag increment with ice comes out to the expected value of 0.01, to balance out the reduction in drag due to the reduction in CDi drag due to CL decreasing with ice.

But now, let's assume the aircraft is trimmed at an AoA of 0 deg, and re-run the calculation.

So with no ice we have:

CL = 0.2394 CD0 = 0.016 CD-i = 0.0022 CD-alpha = 0

So the total drag coefficient =0.0182

Now with ice:

CL = 0.2394 - 0.30 = -0.0606 CD0 = 0.016 CD-i = 0.0001 CD-alpha = 0 CD-ice = 0.01

So the total drag coefficient = 0.0261

So in this case the overall drag did increase, and is only 0.0021 below the expected total drag coefficient, so if you applied the required drag increment of 0.0212 to match the AoA 5 deg case, instead of the published 0.01 then you would be overestimating the drag for the 0 deg AoA case.

[Octal450]

Yeah, I see what you mean.

I'm looking into this.

Kind Regards, Josh

[Octal450]

OK Sean, I'm onboard.

I'll let you know what I come up with.

Kind Regards, Josh

[seanmcleod]

So, a non-aerodynamics question 😉

How come you use a fairly non-standard structural frame origin for positioning items compared to most JSBSim models?

The structural frame is positive backwards, and often/typically something like the nose of the aircraft would be the origin. In your case I noticed all these negative offsets.

-18.8m      Nose
-13.6m      Nose gear
-5.3m       Engine
-2.4m       Empty weight cg
-2.2m       AeroRP
-1.1m       Main gear
0m      Eye Point
0m      VRP
18.7m       Tail

And should the Eye Point and VRP really be at 0m?

[Octal450]

I don't really understand the question.

I position things with the origin 0,0,0 being on the fuselage datum for Z and the X position is usually near CG. If it isn't in the 3D model, I use VRP to move it there. All the coordinates are in reference to the 3D model including the W/B at appropriate MAC.

Kind Regards, Josh

[seanmcleod]

X position is usually near CG...

Except, that's my point, it's very unusual, not sure if I've actually come across other JSBSim models in the JSBSim repo etc. where the origin of the structural frame is near or related to the cg.

https://jsbsim-team.github.io/jsbsim-reference-manual/user/concepts/frames-of-reference/

The Eye Point is supposed to represent the location of the pilot in the aircraft so that for example pilot sensed accelerations can be calculated, which requires a vector between the cg and the pilot's location. So in your case the Eye Point is roughly 13m away from where it should be.

https://github.com/JSBSim-Team/jsbsim/blob/0f00b806a74027d71a3e758bbb1e177e4b6130f2/src/models/FGAuxiliary.h#L56-L80

https://github.com/JSBSim-Team/jsbsim/blob/0f00b806a74027d71a3e758bbb1e177e4b6130f2/src/models/FGAuxiliary.cpp#L406-L411

[Octal450]

I meant "usually" as in for my models. I've found things work best for me when the model is distributed about the origin on the X position.

Yes, I put the EYEPOINT out of my way. It causes FG to erroneously blackout/redout at times, and I don't need any of its pilot sensed calculations. So it's just positioned to get it out of my way.

Kind Regards, Josh

[seanmcleod]

So what do you use for the origin of the X-axis of the structural frame?

It causes FG to erroneously blackout/redout at times...

Do you think it's a bug in FG or JSBSim?

[Octal450]

Sorry not sure what that question is asking. The way is thought of like the center.

I... don't actually know. But I noticed on landing/nlg touchdown he would give erroneous blackout/redout - I assume from the G sensor spikes? Not sure. But since moving it closer to the CG/AeroRP I noticed it didnt cause issues, and didn't really read horribly away from my load factor calc anyway.

Kind Regards, Josh

[seanmcleod]

Sorry not sure what that question is asking. The way is thought of like the center.

What part of the aircraft is the reference for the origin of the X-axis of the structural frame? For example as mentioned in:

https://jsbsim-team.github.io/jsbsim-reference-manual/user/concepts/frames-of-reference/

Often it's the nose tip, propellor tip or firewall etc.

Or in the F-16's case it's specified as the nozzle of the aircraft, and in this case positive X is going forward, hence all negative values in the JSBSim FDM for it.

Aircraft refference locations
(realtive to the centerpoint at the front of the nozzle):

               X            Y         Z
             ------     ---------   ------
Center of Garvity        201.3               0.0          0.0
Pilot's eyepoint     384.7           0.0     33.2
Radome tip       525.0           0.0    -13.0
Top vertical tail      0.0           0.0    127.5
Wingtip          128.0      +/-197.0      0.0
Nose landing gear    332.2           0.0    -73.0
Main landing gear    171.9       +/-46.7    -73.0
Ventral fin      111.1       +/-24.0    -51.3
Air intake       350.7           0.0    -41.0
Fueltank         171.3       +/-71.5      0.0

Given the origin, normally placed at some easily identifiable part of the aircraft by the aircraft manufacturer, other people can take a scale drawing of the aircraft and then use that to place new items in the structural frame. For example, say I wanted to place the A320's APU into your structural frame and I have a scale drawing of the A320 with the location of the APU shown, how do I calculate it's X position in your model?

[Octal450]

I can just specify the datum location in my excel sheet and it does the rest.

But having the origin away from 0,0,0 means you have to deal with a lot of other stuff in FlightGear. Best to approach it from the 3D model point of view.

Stuff like the positions of the ground reactions and such are taken from the 3D model so that the collision points match up.

CG position is based on %MAC which is based on distance from datum iirc.

I did that calculation years ago so exactly what I did I'd have to dig up. I am pretty sure Jonathan told me the %MAC location and I went from there.

But in most of my FDE's, sadly do not have much data. So I have to reverse engineer it.

I would say just calculate the offset from another known point (I usually use MLG for this).

Kind Regards, Josh

[seanmcleod]

But having the origin away from 0,0,0

Hmm, doesn't make sense, by definition the origin is 0,0,0.

But yes, you can place the origin of your structural frame anywhere relative to the aircraft, but the point is it needs to be documented so that others who want to place things afterwards know what it is, especially if it is a non-standard location.

[Octal450]

Sorry. It's late here. I meant by having the center of the aircraft away from 0,0,0.

The nose location is defined in the ground reactions. I guess that is what you are asking for? You want me to document that? Or I guess I'm just not really sure what your asking me to document. You can choose any point as a reference to whatever data you are using.

Kind Regards, Josh

[seanmcleod]

I'm making the point that you should document in the FDM as a comment etc. what the origin of your structural frame is. So that if I or anyone else wants to update your model, e.g. to add the location of the APU as another point mass or even as another engine producing thrust I can work out the structural coordinates that I need to input into your model.

So for most aircraft it's specified as for example the tip of the nose, or in the F-16 as the position of the exhaust nozzle of the engine etc.

[Octal450]

I should probably clarify that you mean "for most" in JSBSim's repo. Most in FGFS do it this way (hence why I started doing it this way also).

OK, I can do that. I'd have to figure out what that point is. I do most of my work relative to the MLG position because this is the most important. MLG to mass distribution has a big impact on the rotation speeds/balance on ground, etc.

Kind Regards, Josh

[seanmcleod]

Yep, I mainly look at aircraft in the JSBSim repo. But the structural frame also is typically defined by the manufacturer so I've seen a lot of those as well.

But yes, you're free to choose your own structural frame origin as long as you're consistent with it. Plus ideally document it for others so that they don't have to reverse engineer it from your model.

For example, given you haven't documented your structural frame origin, I have to reverse engineer it from say the coordinates you've specified for the nose landing gear, in order to come up with the coordinates of say the top of the tail (green dot) that I want to add to your model.

[Octal450]

Hehe. The A320 FDE is actually fairly late in this rendition. I think I have more A320 data than others.

The MD's for example I had very little data for about the structures like that.

OK, so what coordinate do you want. The Nose position? I can add that to documentation. That's the only "structural frame origin" I can think of ever using besides MLG (main landing gear, not nose).

Kind Regards, Josh

[seanmcleod]

I'm suggesting that you document your structural frame origin. So that I or others can then place it on a scale drawing like the one above to take measurements to other points on the aircraft that I may want to add to your model.

of ever using besides MLG (main landing gear

But that's clearly not your structural frame origin at the moment.

[seanmcleod]

I took a quick look at a couple of the FlightGear aircraft I have looked at in the past to see what they do in terms of their structural frame origin.

To be fair, only one of them actually documented it as a comment. I wonder whether we shouldn't add a comment field to the metrics element to encourage the documentation of the structural frame origin.

So this 737 model has a specific comment:

https://github.com/YV3399/737-800YV/blob/master/737-800YV.xml

base datum - nose of aircraft. BWL at this point 208.1 in. Source - structure diagrams.

The C-172p doesn't have a comment, but looking at the values specified it looks like they've probably used the firewall as the origin.

https://github.com/c172p-team/c172p/blob/master/c172p.xml

Lastly the F-15 also appears to, without explicit documentation to use the nose.

https://github.com/Zaretto/fg-aircraft/blob/master/aircraft/F-15/f15a.xml

They all seemed to have EYEPOINTs defined that weren't near the cg.

If you're seeing large g values in the cockpit while landing, maybe there is an issue with the spring and damping values for your gear that are causing these short large g spikes?

[Octal450]

not your structural frame origin at the moment.

Sorry, I think you are assuming I used some thing that I didn't use? Or maybe just a wording barriar of some kind.

If you're seeing large g values in the cockpit while landing

It's been many years. I redid the gear coeff's multiple times since then. I could recheck it sometime. But tbh, I don't use any functionality that the EYEPOINT provides, so it's not a high priority thing for me.

Kind Regards, Josh

[Octal450]

My process starts by defining all contact points. Then I find MAC. Then I find empty CG and AeroRP. Then I create the distributed load for weightmasses around the empty CG including fuel tanks. In fact you will find some fudged numbers just so that the various weights match expected CG MAC%.

Josh

[seanmcleod]

That's the only "structural frame origin" I can think of ever using besides MLG (main landing gear, not nose).

This sentence implied you're using the MLG as the structural frame origin.

[seanmcleod]

I set about to render the origin of your structural frame. So I took your nose landing gear's position and to find the origin of the X-axis calculated a pixel point 13.6519m from the NLG towards the tail. Then to find the origin of the Z-axis calculated the pixel point 4.35683m above the ground.

https://github.com/legoboyvdlp/A320-family/blob/bfb547b95f2ecdceee093be025b7910ba7f1ba8c/FDE/Config/a320-ground-reactions.xml#L8-L13

Which results in the red line to indicate the origin of the X and Z axes.

The height looks a bit off, which might be explained by the distance the landing gear compresses on the ground, although I'm not sure it compresses that much.

The x position of the origin has some discrepancies, since it is ~0.1m in front of the MLG but according to the FDM it should be 1.1393m in front of the origin.

https://github.com/legoboyvdlp/A320-family/blob/bfb547b95f2ecdceee093be025b7910ba7f1ba8c/FDE/Config/a320-ground-reactions.xml#L120-L125

[Octal450]

The 3D model coordinates are used for the position of the LGs.

Bests, Josh

PS: Gonna get to the drag stuff soon. Life's just been busy.

[Octal450]

@seanmcleod I'm looking at this again.

The approach you suggested leaves the Slat Drag out. The coefficient in the aero file is supposed to be summed with the increase from CDi making it wrong if I ignore it and remove CDi.

Adding it to CDalpha would make the table (annoyingly) 3D. Is there a better way to do this? What about in other planes if I need 4 coefficients?

What do you suggest?

I must admit I'm still trying to wrap my head around this.

Kind Regards, Josh