RisingFury
OBSP developer
I've been working with Orbiter's aerodynamics and noticed what I think to be a flaw in the CreateAirfoil function.
The function CreateAirfoil asks you to supply a pointer to a function calculating the lift, drag and moment coefficients, as well as the wing area. The same goes for CreateAirfoil2 and CreateAirfoil3.
The problem is that Orbiter seems to use the wing area when calculating drag, instead of the frontal area! That means the coefficient of drag needs to take into account the chance in frontal area, not just the change in geometry around which the air flows.
Assuming a yaw of 0, the cross section facing the free stream equals = frontal area * cos(AOA) + wing area * sin(AOA). That means that for every airfoil you wish to create, you must call the CreateAirfoil function twice - first time you pass on the wing area and you create a function for lift and drag coefficients of the wing. The second time you call CreateAirfoil, you need to pass it the frontal area, together with a different function for calculating drag coefficient.
To me this seems to be a trap for developers because it probably goes by unnoticed. It's also less efficient then just handling one airfoil in place of two and it is easier to create a function of lift and drag as a function of angle of attack because there's more reference material on the subject...
I would suggest that a developer would need to pass at least the wing area, frontal area and possibly even area from the side (along all three principle axis) for every airfoil he creates.
Now that I've explained what I think the problem is, is there a good reason for why airfoils are set up the way they currently are? Am I missing something?
The function CreateAirfoil asks you to supply a pointer to a function calculating the lift, drag and moment coefficients, as well as the wing area. The same goes for CreateAirfoil2 and CreateAirfoil3.
The problem is that Orbiter seems to use the wing area when calculating drag, instead of the frontal area! That means the coefficient of drag needs to take into account the chance in frontal area, not just the change in geometry around which the air flows.
Assuming a yaw of 0, the cross section facing the free stream equals = frontal area * cos(AOA) + wing area * sin(AOA). That means that for every airfoil you wish to create, you must call the CreateAirfoil function twice - first time you pass on the wing area and you create a function for lift and drag coefficients of the wing. The second time you call CreateAirfoil, you need to pass it the frontal area, together with a different function for calculating drag coefficient.
To me this seems to be a trap for developers because it probably goes by unnoticed. It's also less efficient then just handling one airfoil in place of two and it is easier to create a function of lift and drag as a function of angle of attack because there's more reference material on the subject...
I would suggest that a developer would need to pass at least the wing area, frontal area and possibly even area from the side (along all three principle axis) for every airfoil he creates.
Now that I've explained what I think the problem is, is there a good reason for why airfoils are set up the way they currently are? Am I missing something?
