Missing physics component? My simulation results are off. [0.90]

[Holy-Fire]

To help me build better ships, I programmed a numerical simulator in Mathematica that allows me to input the attributes of the ship's stages and output how far it can go. This was back in the <=0.90 era, I haven't moved to 1.x yet.

I've included in it pretty much everything I could think of (including some not-completely-trivial aspects of the rotating reference frame), but the results are still a bit off compared to what I see in-game. With simple rockets that stay within the atmosphere or briefly exit it, the highest altitude reached is about 1% different from simulation. Not something that would materially affect ship design, but not good enough for a perfectionist like me.

This has been driving me crazy and I've spent several hours trying to isolate the problem. I've recently collected some data from a rocket in flight (after the thrust phase, to keep it simple), applied locally cubic regression with a Gaussian kernel, and investigated the result.

(Edit: The following example, it appears, is merely an artifact of incorrect altitude values reported by the game. But, there is still something I can't account for, which is apparent in longer flights (about 1% difference at 10km).)

For example, I concluded that when my rocket was at 2000m and moving upwards (the direction shouldn't differ materially from straight up, and anyway, I calculated that a slight deviation wouldn't explain the discrepancy) at a speed of 252.1 m/s, the acceleration in-game is -47.77 m/s^2.

What I would expect:

Gravity: -9.81 * (600000/602000)^2 = -9.745

Centrifugal force: (2pi/21600)^2 * 600000 = 0.051

Drag: -0.5 * 0.008 * 1.2231 * 0.2 * Exp(-2000/5000) * 252.1^2 = -41.685

Total: -51.38 m/s^2

So my deceleration in-game is 3.6 m/s^2 lower that what my math says.

I experimented with a lift force proportional to speed, and it does seem to help a bit, but I still don't get consistent results, and I don't understand why there should be such a force - the parts I've used don't have a lift rating AFAICT.

And yeah, I know 0.90 aerodynamics aren't realistic, but I'm not looking for realistic, I'm looking for internally consistent.

Could someone please put me out of my misery and explain what is going on?

Thanks.

Edited May 13, 2015 by Holy-Fire

[Hobbes Novakoff]

I don't know, but it's probably floating-point errors in KSP that are causing your imbalance.

- - - Updated - - -

Either that or just messed-up pre-1.0 aerodynamics.

[ElWanderer]

Does your craft consist entirely of parts with a drag coefficient of 0.2, or do you have some less draggy parts?

I remember I could never get my 0.90 height record simulations to match reality (worse performance/more drag than I predicted) until I realised SRBs had a drag coefficient of 0.3.

[Holy-Fire]

I don't know, but it's probably floating-point errors in KSP that are causing your imbalance.

I doubt it. It's too big of an error. And it's not just something that accumulates over a long time, I can detect differences in short timescales as well.

Either that or just messed-up pre-1.0 aerodynamics.

Maybe... But how exactly are they messed up? What's missing compared to the calculation above?

Does your craft consist entirely of parts with a drag coefficient of 0.2, or do you have some less draggy parts?

I remember I could never get my 0.90 height record simulations to match reality (worse performance/more drag than I predicted) until I realised SRBs had a drag coefficient of 0.3.

Yes. In this example I just have 3 parts - Probodobodyne HECS, Oscar-B Fuel Tank, Rockomax 48-7S. Of course, this happens also with other simple liquid-only configurations.

Edited May 12, 2015 by Holy-Fire

[Korizan]

Drag is not a constant, it will vary based on altitude. Apparently in .9 and below the atmosphere was kind of messed up to make things work.

and / or the drag you are using is not the same number that KSP is using. (example drag of a single part is .2 but KSP is adding up all the parts and assigning a different drag coefficient for the rocket as a whole)

So the question is are your dependencies linear or are they variant based on altitude ?

That should help you narrow down the problem.

[ElWanderer]

For what it's worth, I just opened my vertical launch calculator and fiddled with some values to get a velocity of about 252m/s at 2000m and I agree with your calculated/expected results for gravity and drag.

How accurate are your measured-in-flight values? If your prediction for max alt is only 1% off, I wouldn't expect observed drag to be ~10% away from your calculated value.

I found my results for peak altitude were never quite right. I didn't take into account the rotation, which I always assumed was the culprit.

[KerikBalm]

I thought in KSP, for some reason, surface gravity was 9.82 m/s... though that is not going to account for more than 1% of the error.

"the direction shouldn't differ materially from straight up, and anyway, I calculated that a slight deviation wouldn't explain the discrepancy"

Are you sure? the rotation of Kerbin is quite significant at such a small scale. There was a thread about fins on rockets, and kerbin's rotation was enough that the rockets consistently tipped over into a westward gravity turn with no control input.

[hirschhornsalz]

Your centrifugal force seems to be a bit off, you are using the values at the ground. Assuming you are going straight up relative to the ground, it should be (2pi/21600)^2 * 602000, bit this is not enough to explain the difference.

I agree that most likely either the drag displayed ingame is wrong or nor correctly calculated. But the 0.90 athmospheric model is now obsolete anyway, except you are planning for staying at 0.90 long term.

[Holy-Fire]

Drag is not a constant, it will vary based on altitude. Apparently in .9 and below the atmosphere was kind of messed up to make things work.

and / or the drag you are using is not the same number that KSP is using. (example drag of a single part is .2 but KSP is adding up all the parts and assigning a different drag coefficient for the rocket as a whole)

Well, it seems weird that there would be such a difference. Any insights about how it could work?

So the question is are your dependencies linear or are they variant based on altitude ?

That should help you narrow down the problem.

Ideally I would be able to collect enough data to determine the difference as a function of speed and height. But collecting data is too time-consuming for me. Which mods make it easier to collect such data?

How accurate are your measured-in-flight values?

I mentioned a gap of 3.6 m/s^2; the inaccuracy is enough for that figure to actually be anywhere from 3 to 4 m/s^2, but I doubt it's outside this range. Even if only 3, it's very significant.

If your prediction for max alt is only 1% off, I wouldn't expect observed drag to be ~10% away from your calculated value.

The exact difference in max alt varies; in this case, I predict 3339 m and reach 3404 m, so about 2%. Anyway, the difference of 10% persists only for a short period of time; as the speed goes down, gravity dominates, and seems to work as expected.

I found my results for peak altitude were never quite right. I didn't take into account the rotation, which I always assumed was the culprit.

I doubt it. Centrifugal force has only a small effect, and other rotation effects turned out to be negligible in my calculations, definitely at lower altitudes.

I thought in KSP, for some reason, surface gravity was 9.82 m/s... though that is not going to account for more than 1% of the error.

Isp is calculated based on g=9.82. But the actual g is 9.81 as far as I can tell. Hard to measure ground gravity directly with all the confounding factors, but measuring gravity in orbit confirms that at R=600000 it should be 9.81. I think this was also supported by my measurements of terminal velocity with a parachute, though maybe it wasn't accurate enough to be definite.

"the direction shouldn't differ materially from straight up, and anyway, I calculated that a slight deviation wouldn't explain the discrepancy"

Are you sure? the rotation of Kerbin is quite significant at such a small scale. There was a thread about fins on rockets, and kerbin's rotation was enough that the rockets consistently tipped over into a westward gravity turn with no control input.

Sounds odd - Coriolis force shouldn't apply torque to a rigid body - but it doesn't take much to tip an unstable equilibrium, and it could result from higher order effects. But assuming a point body and talking about max altitude, in the low atmosphere, it's not significant.

Your centrifugal force seems to be a bit off, you are using the values at the ground. Assuming you are going straight up relative to the ground, it should be (2pi/21600)^2 * 602000, bit this is not enough to explain the difference.

Not quite. Yes, the actual centrifugal force is w^2*602000, but, as you go up to 2000, Coriolis force gives you a side velocity of w*2000. Coriolis force from this side velocity applies a downward force of w^2*2000. This exactly cancels out with the increase in centrifugal force. Other affects of the side velocity are negligible in this scenario. So it's safe to simply talk about a constant centrifugal force of w^2*600000.

I agree that most likely either the drag displayed ingame is wrong or nor correctly calculated.

The thing is, it can't be simply "different drag" since simulating a fixed change in drag doesn't result in the experimental trajectory. There seems to be a dependence on the altitude or speed, but I can't figure out what it is.

But the 0.90 athmospheric model is now obsolete anyway, except you are planning for staying at 0.90 long term.

I might. Most of what I've read about 1.x makes me feel I will enjoy it less than 0.90. And this mystery has become a mostly academic thing now, I hope to solve it before moving on.

Is there a way to ask the developers about this? Surely they would know...

[Korizan]

Sadly I can't think of any mods that might help you.

It is a question of does the atmosphere effect the drag like it should and how is the atmosphere worked out.

Did they use a log^ to create it or it just hard boundaries at certain altitudes, I don't know.

Another thought may be a case of truncating you don't know how the game is calculating its numbers, truncating can some serious deviation.

[Holy-Fire]

It is a question of does the atmosphere effect the drag like it should and how is the atmosphere worked out.

Did they use a log^ to create it or it just hard boundaries at certain altitudes, I don't know.

I don't think they use a piecewise function for the atmospheric density. First, it would make little sense for them to do so, since it's actually more complicated; and, it's not consistent with measured results. For example, if you descend with a deployed parachute, your speed will be essentially equal to terminal velocity, and you can see it gradually go down as density increases. If they do use a very fine lookup table, it shouldn't materially affect the results.

Another thought may be a case of truncating you don't know how the game is calculating its numbers, truncating can some serious deviation.

I doubt this is it. The gap is too big to be the result of any sane truncating; and, a game of this type should be expected to use high accuracy - all calculations being done in double, or at least single, precision floating-point, with no rounding except for display purposes.

[arkie87]

To help me build better ships, I programmed a numerical simulator in Mathematica that allows me to input the attributes of the ship's stages and output how far it can go. This was back in the <=0.90 era, I haven't moved to 1.x yet.

I've included in it pretty much everything I could think of (including some not-completely-trivial aspects of the rotating reference frame), but the results are still a bit off compared to what I see in-game. With simple rockets that stay within the atmosphere or briefly exit it, the highest altitude reached is about 1% different from simulation. Not something that would materially affect ship design, but not good enough for a perfectionist like me.

This has been driving me crazy and I've spent several hours trying to isolate the problem. I've recently collected some data from a rocket in flight (after the thrust phase, to keep it simple), applied locally cubic regression with a Gaussian kernel, and investigated the result.

For example, I concluded that when my rocket was at 2000m and moving upwards (the direction shouldn't differ materially from straight up, and anyway, I calculated that a slight deviation wouldn't explain the discrepancy) at a speed of 252.1 m/s, the acceleration in-game is -47.77 m/s^2.

What I would expect:

Gravity: -9.81 * (600000/602000)^2 = -9.745

Centrifugal force: (2pi/21600)^2 * 600000 = 0.051

Drag: -0.5 * 0.008 * 1.2231 * 0.2 * Exp(-2000/5000) * 252.1^2 = -41.685

Total: -51.38 m/s^2

So my deceleration in-game is 3.6 m/s^2 lower that what my math says.

I experimented with a lift force proportional to speed, and it does seem to help a bit, but I still don't get consistent results, and I don't understand why there should be such a force - the parts I've used don't have a lift rating AFAICT.

And yeah, I know 0.90 aerodynamics aren't realistic, but I'm not looking for realistic, I'm looking for internally consistent.

Could someone please put me out of my misery and explain what is going on?

Thanks.

Try turning "hack gravity" on to see if that makes it better or worse (isolate variables). Also try making a craft exclusively from 0.2 drag coefficient parts...

I'd also recommend you use a reliable source for the values you are using. The altitude meter takes time to update (it lags behind correct value) and maybe velocity value isnt updated as fast as required. Perhaps pause the game and take values manually from debug menu or your own plugin?

- - - Updated - - -

I doubt this is it. The gap is too big to be the result of any sane truncating; and, a game of this type should be expected to use high accuracy - all calculations being done in double, or at least single, precision floating-point, with no rounding except for display purposes.

Truncation error CAN cause serious problems for integration (i.e. how high up it goes), but it should introduce negligible instantaneous error (which is what you are reporting).

Furthermore, assuming KSP uses doubles for physics, integration error due to truncation is probably negligible. However, integration error due to step size is for sure not. In this case, you can expect results to match less if you improve the integration scheme, since Unity uses simple forward-euler integration. For best results, you should use forward Euler integration with the same time step.

Edited May 13, 2015 by arkie87

[Frida Space]

Maybe the gravitational acceleration is a bit off? It does decrease ever so slightly as you go up. It could make up for, say, .5% maybe of your 1% margin error

[arkie87]

Maybe the gravitational acceleration is a bit off? It does decrease ever so slightly as you go up. It could make up for, say, .5% maybe of your 1% margin error

if you look at OP's calculations, he accounts for that

[Holy-Fire]

The altitude meter takes time to update (it lags behind correct value) and maybe velocity value isnt updated as fast as required.

THIS. In all of my recent measurements, I used these reported values mid-flight, because I wanted to isolate away the thrust phase. I was hoping they give me the correct value, and I could find the rest by interpolation. But if those are inaccurate... It can easily explain the discrepancies.

So I simulated the short flights from launch, and the discrepancy in max height is small. This still leaves me with a discrepancy that accumulates over longer flights, which is what I started with before trying to isolate things.

Also try making a craft exclusively from 0.2 drag coefficient parts...

I did, or at least I thought I did. Playing around in the debug window revealed that there are two drag values associated with each part. I tried a ship made purely of parts with equal min and max drag, but it doesn't help much.

I'd also recommend you use a reliable source for the values you are using. Perhaps pause the game and take values manually from debug menu or your own plugin?

I didn't find in the debug menu a way to get altitude and velocity values ("Flight debug stats" seems to just have some useless stuff). Can you suggest a way to get the data? If not in stock, perhaps an existing plugin, doing one myself is too much for me.

If I could find a way to measure local values accurately, it will certainly help.

However, integration error due to step size is for sure not. In this case, you can expect results to match less if you improve the integration scheme, since Unity uses simple forward-euler integration. For best results, you should use forward Euler integration with the same time step.

My current setting is max dt/frame = 0.03 sec, which is too low to explain the discrepancy. I use a slightly fancier integration method, but I need a step size of ~2 secs to reach this kind of error. If all else fails I might try to rewrite my integration to match, but I doubt this is it.

[arkie87]

THIS. In all of my recent measurements, I used these reported values mid-flight, because I wanted to isolate away the thrust phase. I was hoping they give me the correct value, and I could find the rest by interpolation. But if those are inaccurate... It can easily explain the discrepancies.

So I simulated the short flights from launch, and the discrepancy in max height is small. This still leaves me with a discrepancy that accumulates over longer flights, which is what I started with before trying to isolate things.

I did, or at least I thought I did. Playing around in the debug window revealed that there are two drag values associated with each part. I tried a ship made purely of parts with equal min and max drag, but it doesn't help much.

I didn't find in the debug menu a way to get altitude and velocity values ("Flight debug stats" seems to just have some useless stuff). Can you suggest a way to get the data? If not in stock, perhaps an existing plugin, doing one myself is too much for me.

If I could find a way to measure local values accurately, it will certainly help.

My current setting is max dt/frame = 0.03 sec, which is too low to explain the discrepancy. I use a slightly fancier integration method, but I nep size of ~2 secs to reach this kind of error. If all else fails I might try to rewrite my integration to match, but I doubt this is it.

Time step only effects integration values. I.e. max altitude. It will have zero affect on instantaneous measurements, like acceleration. That value should still match.

Is there a way in the debug menu to display forces on parts?

If so, use time control mod to slow down time to 1/64 real time. Which is almost like pausing game.

Incidentally, time control mod might also be the easiest way to get accurate readouts....

[Holy-Fire]

Time step only effects integration values. I.e. max altitude. It will have zero affect on instantaneous measurements, like acceleration. That value should still match.

I'll clarify that, now that I know that the instantaneous altitude reported by the game isn't accurate (lags by some amount), I no longer have evidence for a problem in the instantaneous acceleration. I only see a difference in max altitude.

Is there a way in the debug menu to display forces on parts?

None that I've seen.

If so, use time control mod to slow down time to 1/64 real time. Which is almost like pausing game.

Incidentally, time control mod might also be the easiest way to get accurate readouts....

I'll try it. If this solves the altitude lag and I can get fine-grained, accurate altitude measurements, interpolating acceleration is relatively easy.

Update: Time Control turns out to be only marginally useful. Kerbulator, on the other hand, is extremely useful. I'll play around a bit and report what I find.

Edited May 14, 2015 by Holy-Fire

[arkie87]

I'll clarify that, now that I know that the instantaneous altitude reported by the game isn't accurate (lags by some amount), I no longer have evidence for a problem in the instantaneous acceleration. I only see a difference in max altitude.

None that I've seen.

I'll try it. If this solves the altitude lag and I can get fine-grained, accurate altitude measurements, interpolating acceleration is relatively easy.

Update: Time Control turns out to be only marginally useful. Kerbulator, on the other hand, is extremely useful. I'll play around a bit and report what I find.

I once used Time Control to slam into Kerbin's atmosphere at 300,000 m/s (using infinite fuel) at 1/64th time. It was glorious.

[Holy-Fire]

I promised I'd report what I found, so... My results were inconclusive. It seems I could not even get consistent results even with the velocity, let alone acceleration. That is, given a segment where vertical velocity ranged in [a, b], the difference in altitude was outside the range [a dt, b dt]. So there's definitely something weird going on, maybe some discrepancies in the coordinate system. I've given up on trying to replicate it.