plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.


Please take a moment to read the platform’s guidelines before you get started!


question

boufogre avatar image
boufogre asked FlyingRaccoon answered

Drag calculation borked (new topic)

Hello,

Sorry to come back to this topic, but the way the drag is calculated is so wrong.

I have the following parameters set in the flight_model.cfg:

drag_coef_zero_lift = 0.029
lift_coef_at_drag_zero = 0.5084
induced_drag_scalar = 4.5 (this is on purpose and based on real world data

oswald_efficiency_factor = 0.813
AR of the wing is 7.95

According to this, the expect drag is:
Cd = 0.029 + 4.5 * 0.049 * (Cl - 0.5084)²

However, when in the simulator, here is the obtained drag: Cd = 0.09238

1646862565015.png

It should be, for the Cl of 0.60028 visible in the screenshot: Cd = 0.03086

Please, don't say this is because of the scalar. It is because the other_drag is adding 0.0615, on top of the correct calculation.

This is roughly equal to the NEW FM zero alpha drag value, visible on the screenshot below:

1646862906217.png


Could this get fixed ASAP? It really hinders the development of quality and real life data based FM...

Thank you!

aircraftflightmodel
1646862565015.png (2.5 MiB)
1646862906217.png (2.5 MiB)
3 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image FlyingRaccoon ♦♦ commented ·

Hello @boufogre


That 0.0615 is not some random number we generate, it has to come from one of the cause listed in the debug panel.
Most of the time, when we encounter such a problem, it's an error in the control surface areas or a heavy tendency of the aircraft to side slip
Setting a negative value in drag_coef_zero_lift_mach_tab will do nothing but create more problems.

If you're struggling to find where that 0.0615 value is coming from, send me a package and I'll have a look.

Regards,
Sylvain

0 Likes 0 ·
boufogre avatar image boufogre FlyingRaccoon ♦♦ commented ·

Thank you for the help @FlyingRaccoon.


In the context of drag, the 0.0615 quantity is huge. I am convinced that it comes from the fact that the simulator is actually using CDAOA0 as a target CD0, when actually, it should use the CD0 value specified in the file.

As a proof, I invite you to modify the default A320 flight_model.cfg in the following manner:
- set the 0 AOA CL to 0.1 in the corresponding table

- set the CLminD at 0.33 (lift_coef_drag_zero)

- set the induced drag scalar to 4

Now, if you start a flight with 10% of fuel, and 0% payload, and fly at M 0.81 at FL360, the CL will be 0.33 and the CD will be... 0.03806 instead of 0.02370 as per specified in the file.

Here are some screenshots with the above modifications done. I still invite you, please, to do the following experiment. I will attach the modified flight_model.cfg file so you don't have to do the modifications yourself.

a3201.jpga3202.jpg

a3203.jpg

a3204.jpg

0 Likes 0 ·
a3201.jpg (315.2 KiB)
a3202.png (247.0 KiB)
boufogre avatar image boufogre FlyingRaccoon ♦♦ commented ·

The link to the modified default A320 flight_model.cfg:
https://1drv.ms/u/s!AohwTJSZ0H8DgfVEOo_WUvCOykMFMg?e=CwgFn4

0 Likes 0 ·
boufogre avatar image
boufogre answered

I'd be happy to speak to someone at this stage, to clear this up, as this has been going on for so long.

Happy to set up a TeamViewer session and explain what is wrong, and how to correct it. Plus we could speak French, so language would not be a barrier.

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Simbol avatar image
Simbol answered

The main challenge now if this is changed is how it will affect all the products already released which were tweaked somehow to hit required numbers with custom drag scalars, or any other means / resources available.

This is not as easy as it sounds.. this gets changed now.. and it will have lots of ripples effects..

S.

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

boufogre avatar image
boufogre answered Simbol commented

To be honest, if it gets fixed, fixing the already released products shouldn't be a problem at all.

Plus it will allow devs to finally be able to tune their drag correctly.

The problem is that induced drag influences parasitic drag in the sim via the other_drag additive, which is plain wrong.

It has to be fixed, it is not a trivial error.

4 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Simbol avatar image Simbol commented ·

This is very easy to say, but in practical terms it doesn't work like that. Imagine a developer with 7 products already released.. he will need to re-work 7 flight models.. and if such developer has all these products with market place.. it needs to re-submit those for approval to get them updated.. which takes several weeks to reach the end user and in the meantime? you get an incredible back slash from all your customers because something is not working anymore as it should.. I don't want to be in this position, would you?


Imagine the head ache until Market Place can update these products.. and it would not be just 1 developer submitting changes, it will be hundreds of them.. so the ripple effect is very substantial.. and it would leave thousandths of MSFS users with a broken flight model for many months until Market Place staff can catch up..


Add to this hundreds of MODs created by the freeware community, which would be also be affected...

This has already happened before after some Sim Updates..and it was the reason why so many users world wide complained very strong to MSFS to please clean bugs with the sim.

The reality is, if this formula is going to be adjusted after so many products are out there already working and released, it will need to be done in a way to ensure backward compatibility in order to avoid chaos, so for example, a new property under flightmodel.cfg such as useNewDragformulas = 1; with the default value set to zero. So unless you set this to true, old drag coefficients / formulas remain ensuring no current released products get broken.

MSFS is becoming very popular with an incredible amount of add-ons available in the market, therefore this things need to be taken in consideration, we cannot afford to break everything and start all over again with each single update... it is just not viable not only for 3rd party providers but also to Microsoft Market place staff, which is already under an incredible amount of pressure to keep the constant demand to update and release products.

Best,
Simbol

1 Like 1 ·
Sherv avatar image Sherv Simbol commented ·
Simbol, I understand your concern however I think the most important part is for the team to acknowledge this issue and work on a long term fix. We're not saying this has to be fixed immediately. And of course there should be a process put in place to ensure backward compatibility.


Are there any other devs encountering this issue?

1 Like 1 ·
boufogre avatar image boufogre Simbol commented ·

I understand your concerns, and of course my objective is not to break the work of others.


Maybe publishers can release an updated flight_model.cfg file to their customers via their own website, until Marketplace versions get processed.

The amount of change needed to the flight models, if using scalars of 1 or close to 1, should be minimal in any case.


And in the end, I wonder why this error did not get more attention.

You say: "we cannot afford to break everything and start all over again with each single update... ", but let's keep in mind that in that particular case, the sim is broken since released and has yet to be fixed.

It is inconceivable for me that something as basic and essential as drag modelling in a flight simulator cannot be done right, and that every aircraft developer out there has to work around the problem.

I am not here to point fingers and blame, I just want what I consider an important problem, one that affects every developer, to be fixed.



0 Likes 0 ·
Simbol avatar image Simbol boufogre commented ·

The whole idea of releasing by market place is to provide automatic updates, etc. and protect your product via DRM, providing a flight model.xfg via your own website is against this purpose really, and still doesn't change the fact developer X, find itself with 7 broken products as soon as it is released.

It affects everyone, and although you are right, the formulas are incorrect.. hundreds of products have been released and adjusted via drag scalars to hit the required numbers for each flight model.. we can't ignore the fact there are stuff out there working in terms of "results" just fine.

I am not saying this doesn't need fixing, I am saying careful planning needs to be put in place..

S.


1 Like 1 ·
boufogre avatar image
boufogre answered

Another evidence of drag calculation being wrong.

Trying to overcome the problem mentioned above, I have used the drag_coef_zero_lift_mach_tab parameter a set it to: 0:-0.0386.

Doing so, the calculated Cd in the sim comes back to the expected value of ~0.033 for the current conditions of flight.

However, in spite of the Cd being correct, look at the drag force values, and the thrust values.

Basically, my plane, which has a correct Cd with the correction, is now flying at 365 KCAS with idle thrust!

1646911699679.png


The root of this problem is in the Cd0 used in the calculation. Textbook theory is to define Cd0 as the minimum Cd for the airplane, independent of the AOA or any other consideration. In the sim, it is defined as the zero AOA drag coefficient, hence the included induced drag in the sim calculation.



1646911699679.png (2.5 MiB)
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

masterrob94 avatar image
masterrob94 answered Sherv commented

I agree with you Simbol that already released products are also need to get customized for the flight_model fix. I would suggest for a better solution. How about introducing a new flag which is settable to use correct calculation of the flight dynamics? Then default it to "false", so every earlier aircraft won't be affected and devs now should have time to go ahead and get use of those real life values

2 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Simbol avatar image Simbol commented ·
This is exactly my line of thoughts as well.


S.

1 Like 1 ·
Sherv avatar image Sherv commented ·
Yes I agree this would be a good solution if it is possible for Asobo to implement. I know from the last Q and A that Sebastian is hard at work on the ground friction. Let's hope this issue tops his list as well.
0 Likes 0 ·
Buspeegee avatar image
Buspeegee answered

I think there are many areas where we could help Asobo to get the best out of its FM engine (and Jet engine model if).

Current model is an interesting base. It has a few flaws and limitations, especially regarding:

- above drag calc that not match SDK,

- COL position (should be aft COG and not fwd for proper stability)

- final CL vs AOA is deduced from the idoine table and airfoil info,

- lack of compressibility effect on max CL, max AOA, COL displacement,

- influence of leading edge on max AOA,

- resolution of jet engine tables which could be improved (especially N2 to N1)

These are many areas we could vastly improved by implementing additional entries in the flight model and engine files without busting too much effort on Asobo side.

I am volunteer to help if needed. I live in France if it can be an argument

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Alec246 avatar image
Alec246 answered masterrob94 commented

Very nice find! Do you have a Discord? Wouldbe nice to talk aerodynamics with you if you do! Let me know

1 comment
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

masterrob94 avatar image masterrob94 commented ·

We are on Salty 747 Project Discord

https://discord.gg/JUuAdDXdjV

0 Likes 0 ·
masterrob94 avatar image
masterrob94 answered masterrob94 commented

Weird Math is going on here :-D

asobo-math.png


asobo-math.png (91.6 KiB)
3 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image FlyingRaccoon ♦♦ commented ·
Hello @masterrob94

I'd be interested to know how you got this result. The tests I've done game me correct results.
Are you able to produce this error again and if so, how?

Thanks
Regards,
Sylvain

0 Likes 0 ·
masterrob94 avatar image masterrob94 FlyingRaccoon ♦♦ commented ·

Steps to reproduce this error:


1. pre-compile an aircraft project
2. start Sim
3. open project
4. load up the aircraft and note current value on Aircraft Editor -> Debug -> Sim
5. do some changes to induced_flaps scalar
6. re-compile the project
7. resync on aircraft editor
8. compare value on Aircraft Editor -> Debug -> Sim if calculation is correct according to changes

1 Like 1 ·
masterrob94 avatar image masterrob94 FlyingRaccoon ♦♦ commented ·
if the value 0.7 is set to 0 it calculates correctly


0 Likes 0 ·
FlyingRaccoon avatar image
FlyingRaccoon answered

Hello @boufogre

We spent some time running tests on the A320 with the modifications you mentioned.
The big difference between the target CD and the final CD in this case has multiple causes.

- The induced drag scalar set to 4 is kind of an aberrant value. Above 2, the normalization process will not be accurate. It will match on the 2 reference points we consider (AOA 0° and 12° AFAIK) but will have very different values everywhere else.
A bit like this:
1649686636161.png

Instead of:
1649686650378.png

- What's your elevator position when you check your drag values?
On the A320, the elevator has a big influence on the drag. It will change the AOA where you have Cd0 and Cl0.

- Finally, keep in mind that you can't just rely on the normalization to compensate for the difference between target parameters and actual results. The normalization helps a lot but it can't do "miracles". The first priority is to configure the flight model so that it gives results as close as possible to target parameters so that normalization only has some minor adjustments to perform.

What we are going to change:

Aiming for SU10, we're going to expose some additional debug information and configuration parameters.

- The drag debug window will now show the polars so you have a better view of the match between theoretical model and actual FM. It will also show when you have values that we consider too extreme

1649687487263.png

- We will expose new parameters to configure normalization:

clcd_normalization_aoa_deg_low : Lower AOA at which the aircraft's lift & drag is normalised to the theory curve.

clcd_normalization_aoa_deg_high : Higher AOA at which the aircraft's lift & drag is normalized to the theory curve.

1649687698934.png


- We will expose new parameters to adjust the drag:

wing_mindragincidence : Aircraft AOA at which the wing's parasitic drag is minimal. (Lift induced drag is always minimal when lift is minimal).

fuselage_mindragincidence : Aircraft AOA at which the fuselage's drag is minimal.


We think all of this will greatly help you. Let us know if you have any feedback.

Regards,
Sylvain


1649686636161.png (58.6 KiB)
1649686650378.png (57.6 KiB)
1649687487263.png (611.9 KiB)
1649687698934.png (176.9 KiB)
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.