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

[SirSock]

SirSock, Maxwell Fern,

Open the FAR window from the Space Center view. You can modify the maximum stress for several classes of parts in Aerodynamic Failure, or completely disable them in Debug Options.

Thanks, that helped a little. I still find it rather silly how my straight-wing F-80c fighter jet can pull out of a dive at 500 knots doing over 15g yet my delta-wing space plane can't go into a stall at about 150-knots without the wings tearing apart.

[TeiwazVIE]

If you stop to think it's not as strange as it seems.

It's because the wheels are not perfectly at the same height.

Then, with angle, when you put them open like that each of them is trying to pull the aircraft outwards.

Any imperfection on the symetry, node position, part configuration, anything that makes the weight on one of the wheels to be even slightly bigger than on the other will cause one to have "more grip".

When that happens, they tend to make the aircraft to go unstable at takeoff.

Some designs have bigger effect than others, some go totally unstable, others have issues at landings.

So yeah, that happens.

Oddly enough that fixed it. Thx again for the hint. You're right, it does make sense but what doesn't make any sense at all is that it's actually happening

Sorry for blaming it on FAR, didn't know that it's actually a Kerbal bug.

[tetryds]

Yeah, with soft tires the effect shouldn't be so intense.

The fact that landing gear wheels are solid like rock, and the way KSP handles grip amplifies that effect, turning it into a common cause of catastrophic failure (both with and without FAR).

If you didn't notice it before it may be simply because on FAR you may be going much faster.

[TeiwazVIE]

Yeah, with soft tires the effect shouldn't be so intense.

The fact that landing gear wheels are solid like rock, and the way KSP handles grip amplifies that effect, turning it into a common cause of catastrophic failure (both with and without FAR).

If you didn't notice it before it may be simply because on FAR you may be going much faster.

Catastrophic failure is a pretty good phrase - extremely losing control on very low thrust and just going ~30m/s on the runway reminded me of downhill riding a shopping cart, which you probably would have more control of

Can't say I had much experience with planes on vanilla KSP before, but no, never had that happen - so for me it really seemed like an issue with FAR.

Now on to fix my infinite glide/acceleration issue

[jofwu]

Is anyone up for the challenge of explaining how FAR calculates a ship's drag coefficient and cross-sectional area? I've been digging through the code, but it's a lot to sort through and it sure would be helpful if I at least knew what to look for. Here's what I know so far:

Wings have the FARWingAerodynamicModel module and other parts have the FARBasicDragModel module. It sorts through all of the parts in a ship and sums the Cd calculations. Shielded and nonphysical parts are ignored. For each part, I assume most of the Cd value comes from open stack nodes (relative to their size). And it seems like there's a 0.003 added for skin friction? (all parts?) The Cd for each part is multiplied by some function of velocity/mach number. For wings I expect it's a bit more complicated- has to account for drag created by a nonzero angle of attack. Surely they produce some drag even for 0 AoA? Maybe that 0.003 applies? Area is calculated based on open stack nodes (relative to their size). So... anyone care to help me from here?

Imagine a very simple ship: small parachute, Mk1 pod, two FL-T800 tanks, and an LV-T30. For bonus, throw two of the small winglets on at the bottom. What would FAR calculate the cross-sectional area and drag coefficient to be (given 0 angle of attack) at Mach 0.1, 0.5, 1, and 2?

[tetryds]

Talking about drag, I know that this has been asked before, but are we ever getting a Center of Drag indicator?

And if not, why?

[ferram4]

@jofwu: You would also need to account for the shape of the mesh at those angles. If you're really curious, the data can be grabbed in the editor, with the static analysis graph giving you your coefficients and the stability deriv tab spitting out reference area.

@tetryds: Because a center of drag indicator separate from the center of lift indicator would be worse than useless; it would only be confusing for everyone trying to use it. Besides, the CoL indicator is already set up to account for drag as well as lift, so you already have what you want.

This is really why I hate the term "Center of Lift" and would prefer people use "Aerodynamic Center" for this: it makes people think the only force that matters for stability is lift or it makes them think that a "Center of Drag" is necessary to account for drag. But the problem is that there's no easy way to compare the stabilizing / destabilizing effects of the various centers quickly; which one dominates cannot be easily conveyed in two separate indicators.

Basically, there isn't a separate one because it's useless, a worthless idea, and its effects are already accounted for by the aerodynamic center indicator.

[tetryds]

Thanks for the more detailed explanation.

That explains a lot, also explains some "strange" behaviours I had when using drag to balance airplanes.

Aerodynamic center sounds great.

[Kalloran]

As someone who only with x64 has started using FAR (and is absolutely loving it), I must ask: So ferram, when are you going to incorporate a numerical solver for the Navier-Stokes Equations into FAR?

[rdswo]

Not totally sure if this is a bug or not but when I have parts attached radially to a rocket their drag mainly pulls the rocket to one side, making it very difficult to launch things straight without stacking them with reaction wheels. I've tried reinstalling FAR, verifying KSP file integrity through steam and removing all other mods (except for MM) but the problem persists, if it is in fact a problem and not something I just didn't notice in the past.

I don't know if it helps at all, but here's some screenshots of the CoL being weird http://imgur.com/a/zIb7Y and an output log https://www.dropbox.com/s/ov839zab6f1zci6/output_log.txt.

[ferram4]

@Kalloran: I see you like low framerates. I too, like low framerates. But no, most people do not like low framerates, so I will not add something that will cause low framerates.

@rdswo: Adding draggy things sticking out of the rocket causes the aerodynamic center to move towards them. That's completely expected and intended behavior.

[rdswo]

@Kalloran: I see you like low framerates. I too, like low framerates. But no, most people do not like low framerates, so I will not add something that will cause low framerates.

@rdswo: Adding draggy things sticking out of the rocket causes the aerodynamic center to move towards them. That's completely expected and intended behavior.

Yeah, I know that much . But what I meant to say was that even though the parts are in symmetry mode the drag seems asymmetrical causing my rockets to turn on their own and start flipping. I've played with FAR for a while but I never noticed this until updating to 0.24.

In my RO save I hardly leave the launchpad before the ship keels over because I have radially attached SRBs, and some life support containers attached to the pod.

[tetryds]

Yeah, I know that much . But what I meant to say was that even though the parts are in symmetry mode the drag seems asymmetrical

I see you are using an engine which has a 4 engines cluster.

There is your asymmetry.

@Ferram: If you could (were able to) send those maths to the GPU it would help in any way?

I like low framerates.

No I don't know much about programming.

Edited August 2, 2014 by tetryds

[Wanderfound]

Is there a way to tone down the mid-air unplanned rapid dis-assemblies? I find it kind of unbelievable that my plane designed to fly at thousands of meters per second can't go into a stall at any speed or altitude without bursting into pieces, even purposefully putting myself into a stall by flying really slow (just to see if I can recover) pulls the wings off almost all of my designs that have more than one part in each wing.

Strutting your wings a bit should substantially toughen them up, BTW, even if they're multi-part. Strut from the underside if you don't like the aesthetics.

However, some topside strut placement can also give you cool angular reentry effects:

[rdswo]

I see you are using an engine which has a 4 engines cluster.

There is your asymmetry.

Ohh...? I don't understand that, but the solid boosters I had radially which I thought were causing the weird drag do have 4 engines, and after removing the it worked. I just assumed it was FAR's fault when the CoL started pointing sideways after I added the boosters.

I don't understand why having 4 engines in a cluster would cause instability in symmetry mode, unless each engine had separate thrust and the game didn't rotate them properly to make it all balanced?

Anyway the rockets are going upwards now with specifically 1 engine'd boosters, thanks for sharing that bit of information, sorry for blaming it on FAR.

[jo_hova]

I am consistently having the problem where every time I load a saved game KSP Crashes. It only occurs with Ferram Aerospace. Has anyone else encountered this problem.

[tetryds]

I don't understand why having 4 engines in a cluster would cause instability in symmetry mode, unless each engine had separate thrust and the game didn't rotate them properly to make it all balanced?

Just because it's centered don't assume it's balanced.

When you have incompatible symmetry modes you will end up having drag force shifted to the side.

The higher this misplaced Aerodynamic Center gets, the worse the effect.

Avoid using anything with incompatible symmetry while using FAR.

The only symmetry which is incompatible is the 3x, it only matches with itself and 6x. (and 1x, always, haha)

All the others can be used at will.

[jo_hova]

I think I have found the culprit. Engineer Redux and Ferram don't get along.

[NoClass]

I don't know if it helps at all, but here's some screenshots of the CoL being weird...

Y'all correct me if I'm wrong.

In the VAB, the windline for CoL calculation purposes assumes that air flow is coming from the open door, rather than the roof (which is the way most rockets would be pointed). To get an accurate CoL using FAR, one must rotate a rocket to point out the door.

Also the vector arrow on the "CoL" indicator doesn't appear to mean anything.

(y'all can add me to the list of people who prefer the use of "Aerodynamic Center" to "Center of Lift")

Edited August 2, 2014 by NoClass

[Sevio]

Hi ferram,

After a long time of sticking with stock's aerodynamics, I've started using FAR in the last few days, after a lot of engineering I've managed to produce a spaceplane that stays stable all the way to orbit, however after docking with a space station and trying to reenter, it will flip out of control below about 40 km no matter what I do. At first I thought it might be because of poor stability with the tanks emptied, then I noticed something odd: all control surface input seems to be inverted when I try to reenter this plane:

http://puu.sh/aBDbY/e6292f3371.png

http://puu.sh/aBDhJ/454eeb9694.png

What's also odd to me is that it's showing a negative L/D and Cl, even though the plane is clearly pitched up in the second picture. I have tried exiting the game and reloading after undocking to see if it would be fixed, but nothing seems to help. Also every time I quickload and undock from the station to deorbit, the UI will start rapidly toggling on and off, which forces me to exit to the space center and come back.

When I spawn a new version of the plane, the control surfaces behave as expected, but two different versions of the plane that I sent up both have the same problem when reentering.

I have tried to do the deorbit without FAR installed and the control surfaces work fine without it, and there is no ui toggling glitch during the deorbit timewarp.

Edit: When the ui glitching happens, the log is spammed with these errors:

[Exception]: ArgumentException: Value does not fall within the expected range.

Mods in use:

Enhanced Navball 1.3.2

FAR 0.14.1.1

Kerbal Alarm Clock 2.7.8.0

Mechjeb 2.3.1.270

Procedural Wings 0.8

Procedural Fairings 3.08

RCS Build Aid 0.4.6

Spaceplane Plus 1.3

Edited August 2, 2014 by Sevio

[Hodo]

Sevio are you running KSP .24.2?

And did you choose control from here on another command module or docking ring? And not choose to control back at the cockpit of the craft?

[Sevio]

Sevio are you running KSP .24.2?

And did you choose control from here on another command module or docking ring? And not choose to control back at the cockpit of the craft?

I am running .24.2, the spaceplane had a fuel tank in its cargo bay with an upward-facing docking port. I used control from there to dock with the station, then detached the tank from the cargo hold when I wanted to leave. So the docking port I once controlled it from is no longer on the ship on reentry. I've made sure to rightclick the cockpit and choose "control from here" before reentry but it still happens.

[rdswo]

I think I have found the culprit. Engineer Redux and Ferram don't get along.

They work fine together for me, do you have the latest versions of both?

[tetryds]

Sevio, did you try putting another command pod or probe on the ship and selecting "control from here" on it?

Or tried docking and going for reentry without selecting "control from here" on the docking port?

The control change seems to be the issue.

Edited August 2, 2014 by tetryds

[NathanKell]

Y'all correct me if I'm wrong.

In the VAB, the windline for CoL calculation purposes assumes that air flow is coming from the open door, rather than the roof (which is the way most rockets would be pointed). To get an accurate CoL using FAR, one must rotate a rocket to point out the door.

Also the vector arrow on the "CoL" indicator doesn't appear to mean anything.

(y'all can add me to the list of people who prefer the use of "Aerodynamic Center" to "Center of Lift")

In the SPH this is true, it comes from the door. In the VAB, it comes from above. Basically, the "wind" aligns with the default direction parts are oriented in.