[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Milkshakefiend]

I think I recall a while ago someone demonstrating a bug whereby FAR will shield a pWing connected to the exterior of a B9 cargo bay - has this been fixed?

[Taverius]

There isn't a stock wing close to this one I don't think. I will wait for ferram to weigh in on all this. Thanks a ton for your help so far!

Everything in the FAR config files has a value of 'e' between 0.7 and 0.9, so just use whatever the stock swept wing does.

None of the existing values are accurate, since there are no accurate formulas for 'e' anywhere.

[Drew Kerman]

I think I recall a while ago someone demonstrating a bug whereby FAR will shield a pWing connected to the exterior of a B9 cargo bay - has this been fixed?

Probably not - I just noticed earlier that a part (one of Klockheed's smart parts, the altitude sensor) I had attached to the outside of a procedural fairing showed up as shielded

[DresCroffgrin]

Everything in the FAR config files has a value of 'e' between 0.7 and 0.9, so just use whatever the stock swept wing does.

None of the existing values are accurate, since there are no accurate formulas for 'e' anywhere.

The first part is true, the second depends on how accurate you actually need. Oswald efficiency (e) always has a value between zero and one, usually tending towards the 0.8 range (0.7 to 0.9 is a very realistic range). However, there does exist a formula to calculate it (at least pre-stall) in Prandtl lifting line theory. However, this formula involves going deep into the derivation of the theory (it deals with a summation of an infinite number of coefficients) and is a bit of a pain, but it does give results accurate enough for FAR (in my opinion).

[DaMichel]

I think I recall a while ago someone demonstrating a bug whereby FAR will shield a pWing connected to the exterior of a B9 cargo bay - has this been fixed?

That was me, and it still happens. The latest FAR version has at least a fix so that the shielded flag is likely to reset when you disconnect the wing again.

Re Oswald Efficiency: Because i was messing with pwings i did google this some time ago and found an interesting paper http://www.fzt.haw-hamburg.de/pers/Scholz/OPerA/OPerA_PUB_DLRK_12-09-10.pdf I have a hard time understanding any of this. Apparently there are a whole lot of methods to calculate "e" and this paper gives an overview. I thought i should post it for the engineering people here.

[Drew Kerman]

well let's just go back to considering basic aerodynamic principles then. We'll say 0.7 is the low value and 0.9 is the high. This wing in particular has a low sweep angle and is very long, so it should be rather efficient and rate around a .85?

[thorfinn]

...guys, do you think that it could be a good idea to move the work we're doing to the main KSP wiki?

The wiki system of Github is really an afterthought, and there are some mod tutorials on the main wiki already. Also, a lot more people would see it.

[DresCroffgrin]

well let's just go back to considering basic aerodynamic principles then. We'll say 0.7 is the low value and 0.9 is the high. This wing in particular has a low sweep angle and is very long, so it should be rather efficient and rate around a .85?

That logic is sound. It should be noted, however, that near elliptic wings (e.g. some trapezoidal wings and actual elliptic wings such as WWII fighters) can get very close to an e value of 1.

[Drew Kerman]

...guys, do you think that it could be a good idea to move the work we're doing to the main KSP wiki?

The wiki system of Github is really an afterthought, and there are some mod tutorials on the main wiki already. Also, a lot more people would see it.

I'd let ferram decide that. Regardless, a direct link to the Wiki in the OP would be a good idea. Most people won't know to check on the gitHub page

[thorfinn]

Let's wait for Ferram's decision, yes.

Oh, and by the way. I don't know whether this is a bug, it probably isn't, but I accidentally managed to build something that resembles so much a FAR infiniglider that I'd like for you to take a look at it.

Javascript is disabled. View full album

[wizzlebippi]

That logic is sound. It should be noted, however, that near elliptic wings (e.g. some trapezoidal wings and actual elliptic wings such as WWII fighters) can get very close to an e value of 1.

First, e=1 means the wing has a perfectly elliptical lift distribution, not planform. Modern airliners are designed to have e be very near 1 at cruise to minimize drag via blended airfoils, twist, and taper. Second, aspect ratio tends to be inversely proportional to e because more of the span behaves in a 2D'ish manner making lift distribution more rectangular. Finally, e's effect on lift and drag is a second order at best. Leaving it between 0.7 and 0.9 won't hurt anything.

[DresCroffgrin]

First, e=1 means the wing has a perfectly elliptical lift distribution, not planform.

Absolutely true, although elliptic planforms are one way helping to achieve this at low speeds with constant airfoils at no twist.

Second, aspect ratio tends to be inversely proportional to e because more of the span behaves in a 2D'ish manner making lift distribution more rectangular.

Quoted just so I can add that taper can help keep e closer to 1 for high aspect ratio wings.

Finally, e's effect on lift and drag is a second order at best. Leaving it between 0.7 and 0.9 won't hurt anything.

Also true. I mentioned it more for completeness and an excuse to post a link about the Spitfire than necessity.

[MAKC]

ferram

Does FAR emulate the effects airfoils can impinge on other adjacent airfoils such as tip vortexes, re-energized flow or turbulence? Keyword here being emulation.

Edited May 27, 2014 by MAKC

[wasmic]

I found out that infinigliders are actually possible in FAR. If you have a quite light craft and use control surfaces that have instant response (the old ones, not the new ones that take some time to reach full... angling? deflection?), and you toggle SAS on, SAS will sometimes make the control surfaces flap so fast that you can go from ~100 m/s to over 1000 m/s, while climbing. Currently, I've only made this happen with Bobcat's Kliper, though, so it is a quite niche bug.

[ferram4]

@thorfinn: It's losing altitude and velocity. That means that it's losing both potential and kinetic energy to somewhere. That's not an infiniglider, it just has a good glide ratio. And yeah, that happens; it's a result of the engine being stupidly heavy combined with the low speeds on Kerbin making the stage act really weird. Nothing I can do about it.

@MAKC: The only interactions that FAR can really simulate are wing parts being part of a single wing (sorta-kinda) and reduction in lift due to wings interfering with each other (like on biplanes). All the others are somewhat difficult to do, and modeling turbulence is completely unnecessary given that it is already taken up in the modeling that FAR currently does.

@wasmic: Yes, when you use control surfaces that still use the stock control surface code (which causes infinigliders) you can get infingliders to work even tough FAR is installed. What should I do, turn wings that aren't set up to be FAR-compatible into useless things instead?

[luckyhendrix]

Hello,

I have a bug with my latest design. The FAR analysis crashes ( NAN value etc ...), but If I check the empty fuel tanks button, it works fine

Here are images of the bug and the plane:

http://i.imgur.com/U2oALcy.png

[http://i.imgur.com/BkQq7eE.png

On a side note, I have some trouble with this plane lateral stability, It has a tendency to roll and it gets worse with speed, any idea to correct this ? I've tried putting a bigger tail, but it make it look ridiculous ,and I don't think I can put more dihedral on the main wings.

[ferram4]

That means that you have an engine that suffers from the NaN ElectricCharge bug. Not a bug in FAR, that's a bug in the modded engine you're using.

As for the lateral stability issues, that's to be expected considering how far back the CoM is. You either need to mount a tail on it so your vertical stabilizers can be further back or you need larger vertical stabilizers altogether. Ridiculousness is not an excuse for not using what works.

Also, get rid of all the dihedral you have on the canards and wingtips. You shouldn't need it for the designs you ave here, and it's just going to make the plane behave worse if you don't have a large enoguh vertical stabilizer.

[Volt]

Is there any solution we as code-laymen can use to fix that engine bug? It's happening with all B9 engines with a generator, and Bac9 is MIA, so if any fixes are going to be made, it's gonna have to be us. And B9 has some truly beautiful engines that would be great to be able to use.

[BudgetHedgehog]

Is there any solution we as code-laymen can use to fix that engine bug?

@PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]
{
	@RESOURCE[ElectricCharge]
	{
		%isTweakable = false
		%hideFlow = true
	}
}

Might want to include ModuleEnginesFX in there, but I haven't seen any of those that aren't already like this so I don't think it's necessary. Oh and B9 is working on an update for, I think, 0.24

Anyway, ferram, I have a feature request... Well, two. 1, could we have an 'X' button on the various pop up windows FAR can toggle? You can keep the button toggle behaviour, I'd just like to have an 'X' in the top right corner too. As far as I know, FAR is the only mod that toggles new windows (apart from it's main one) that lack an 'X'. 2, would it be possible to disable all flight assistance toggles once out of atmosphere? It's happened a few times where I don't realise why my craft has phantom spinning while out of atmo (even the Manley one got caught out by this) just after an ascent (and falling victim to the first request, I found it's quicker to just click the Toolbar button to remove all windows).

Edited May 29, 2014 by ObsessedWithKSP

[luckyhendrix]

That means that you have an engine that suffers from the NaN ElectricCharge bug. Not a bug in FAR, that's a bug in the modded engine you're using.

As for the lateral stability issues, that's to be expected considering how far back the CoM is. You either need to mount a tail on it so your vertical stabilizers can be further back or you need larger vertical stabilizers altogether. Ridiculousness is not an excuse for not using what works.

Also, get rid of all the dihedral you have on the canards and wingtips. You shouldn't need it for the designs you ave here, and it's just going to make the plane behave worse if you don't have a large enoguh vertical stabilizer.

Thanks I replaced the engines, and put A bigger tail, it nows lies quite well when subsonic, But when going super sonic my Xw is becoming negative, and I have no idea how to counteract this

[Taverius]

Oh and B9 is working on an update for, I think, 0.24

One of the things missing from the community patch is there are a couple of B9 engines that have an alternator but lack the resource block outright. Can't remember which ones, it was like 150 commits ago on trunk

Also, it might be for 0.23.5, depends just on how long we take.

[Drew Kerman]

edit: Craaaaap I just though to measure the straight wing in the SPH using the 1m girder segments and the wing turned out to be larger than 10m, which I measured it as in Blender. So I went and took another look at all the part cfg files and....

rescaleFactor = 1.118

So, since I already admitted to being a mathematical moron how would I apply this value to my current 1x scale measurements to come up with better-working values? (damn I didn't make note of actual part surface area values...

Alright, I did the work converting the major airplane surface parts for Coffee Industries mod into FAR-compatible parts, as was discussed starting back here earlier in the thread. Here's what I ended up with:

@PART[planeWingSweptN]:NEEDS[FERRAMAEROSPACERESEARCH]
{
  // zero out all stock values, remove stock module
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
    @ctrlSurfaceRange = 0
    @ctrlSurfaceArea = 0

    // add custom FAR values
    MODULE
    {
        name = FARControllableSurface // or FARWingAerodynamicModel for non-controllable wings
        MAC = 2.28  // Tip = 1.06m | Root = 3.5m
        MidChordSweep = 16.55 // Leading sweep 21.8* | Trailing sweep 26.58* (from start of sweep) | 11.3* (from start of root) <-- value used
        b_2 = 10 // Root to tip in meters
        TaperRatio = 0.30 // Ratio of tip chord to root chord
        e = 0.87 // Drag per lift, lower equals more drag (based on FAR setting for Squad swept wing)
        nonSideAttach = 0  // 0 for canard-like / normal wing pieces, 1 for ctrlsurfaces attached to the back of other wing parts
        maxdeflect = 15  // Default maximum deflection value; only used by FARControlableSurface
        ctrlSurfFrac = 0.09 // Value from 0-1, percentage of the part that is a flap; only used by FARControlableSurface
    }
}

@PART[planeWingStraightN]:NEEDS[FERRAMAEROSPACERESEARCH]
{
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
    @ctrlSurfaceRange = 0
    @ctrlSurfaceArea = 0

    MODULE
    {
        name = FARControllableSurface
        MAC = 2.25  // Tip = 1.5m | Root = 3m
        MidChordSweep = 4.25 // Leading sweep 8.5*
        b_2 = 10 
        TaperRatio = 0.5 
        e = 0.85 
        nonSideAttach = 0  
        maxdeflect = 15  
        ctrlSurfFrac = 0.12 
    }
}

@PART[planeWingHori]:NEEDS[FERRAMAEROSPACERESEARCH]
{
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
    @ctrlSurfaceRange = 0
    @ctrlSurfaceArea = 0

    MODULE
    {
        name = FARControllableSurface 
        MAC = 1.13  // Tip = .61m | Root = 1.65m
        MidChordSweep = 15.94 // Leading sweep 25.02* | Trailing sweep 6.85*
        b_2 = 3
        TaperRatio = 0.37 
        e = 0.8 
        nonSideAttach = 0  
        maxdeflect = 15  
        ctrlSurfFrac = 0.35
    }
}

@PART[planeWingVert1]:NEEDS[FERRAMAEROSPACERESEARCH]
{
    @module = Part
    @maximum_drag = 0
    @minimum_drag = 0
    @angularDrag = 0
    @dragCoeff = 0
    @deflectionLiftCoeff = 0
    @ctrlSurfaceRange = 0
    @ctrlSurfaceArea = 0

    MODULE
    {
        name = FARControllableSurface 
        MAC = 2.09  // Tip = 1.25m | Root = 2.93m
        MidChordSweep = 16.55 // Leading sweep 42.11* | Trailing sweep 18.94*
        b_2 = 3 
        TaperRatio = 0.43
        e = 0.7 // vertical surface, not meant to generate much lift 
        nonSideAttach = 0  
        maxdeflect = 15  
        ctrlSurfFrac = 0.23 
    }
}

However, I think I'm still missing something because the performance of the parts in the game isn't quite as expected. Here's the test aircraft:

And here are the FAR windows:

The main issue seems to be the pitch-up angular acceleration remaining positive even down close to 0 mach. I believe this is why I can't get the aircraft to take off at all, even when I fly it off the end of the runway out over the water at over 100m/s. It just noses down and splashes with full up elevator trim (even using both the wings and tail as elevators).

I'm thinking it's either my e values - which we all still don't fully understand - or the way I'm handling all these parts as FARControllabeSurface. These parts all have control surfaces on them and perhaps I've totally screwed up the ctrlSurfFrac values for them. Or, I've made a fundamental mistake in my measurements - which wouldn't be surprising as I am an unabashed mathematical moron.

I could probably experiment on my own for hours to figure this out - would rather ferram or anyone with actual knowledge of all this to point me in the right direction though. Thanks for all the continued help...

note: I just realized that for the Swept Wing, I used the surface area masurement provided to me by Blender, which gives the surface area of the part, which is not in the shape of a trapezoid. So the ctrlSurfFrac value is definitely off there, but that part isn't used in this design. All other parts are regular trapezoids and so the surface area of the part model should be accurate of how FAR would see the airfoil.

Edited May 30, 2014 by Gaiiden
god dammit

[ferram4]

Those numbers look perfectly fine, it just sounds like your plane is too statically stable in pitch or you don't have enough pitch authority for it to fly. Odds are that the best way to solve it would be to add a small positive angle of incidence to the main wing or a small negative angle of incidence to the tail. Now, it does say that it's dynamically unstable in pitch, which means that it really needs a larger horizontal tail to damp that out, but for now it should be fine.

Also, Oswald's efficiency isn't as big a deal as everyone seems to be making it out to be. The standard way to handle it is to assume that it's 1 and run through the calculations ignoring its effects and the numbers aren't hugely wrong as a result; the difference will not cause any of the issues you're seeing.

If you can't get full pitch up to put the moment coefficient on the static graph at 0 at the same value that produces the lift coefficient that the stab deriv tab says you need, then you won't be able to fly at that speed.

[NathanKell]

Yeah, CoM is *way* too far forward of AC. Move the fore wings forward, or add ballast near the tail.

[Drew Kerman]

thanks for the advice guys, I will give it a go tomorrow. Would it be a good rule of thumb to get the CoM ball to touch or rest on top of the axis sticking out the "front" of the CoL ball?

Also, I just figured out how to do better measurements in Blender and how to easily deal with part scaling. So once I get a successful test flight I will update the wiki with a complete Blender2.7 tutorial for getting FAR values from models

Edited May 30, 2014 by Gaiiden