Mini-challenge: max altitude with this supplied spacecraft

[Katalliaan]

Once .14 comes out, someone will have to use that C# tool to design an ASAS mosule that not only holds the craft steadily on course, but varies the throttle so as to achieve the theoretical perfect ascent.

I was considering doing that, although I would need to figure out what values and calculations I would need. It\'d be faster to tailor it to the craft, but it\'d be better if you could write it to work with any craft.

[Kosmo-not]

We\'re getting that kind of capability with 0.14? That\'s going to be awesome.

[Katalliaan]

Well, we\'re getting the ability to write .dll files to make custom part types, and I\'d imagine that we\'d be able to hook into things such as throttle control, vertical velocity, and fuel amounts.

[Zephram Kerman]

Here\'s a chart of my actual ascent profile on my best attempt. Is this data useful? Just like the thread consensus, the best performance seems to be a product of matching the profile closely during the first and last seconds. Unfortunately, that\'s also when the throttling functions are the most dynamic. Looking at it this way, I can see I need to be more aggressive throttling up just before burnout.

[closette]

@Zephram,

The chart is very useful, and thank you for taking the time to make it (with video capture, presumably).

@izkierka - I would suggest throttle steps of 10% to speed up your heroic iterative process, then you can refine within those steps once you are close to optimum.

[jebbe]

I have finally found some time and implemented an optimizer myself - basically the same thing Kosmo-not did in his excel sheet, I just took much smaller time steps (0.001s in this case, but can be chosen freely). I have attached a graph with the results; the max height in the attached image was 33291m.

Some issues I stumbled upon:

• 
  [li]There is a huge dependence on small changes in the parameters. For example, if I take a drag coefficient of 0.2 instead of 0.2027 I get a height of 33883m, which is quite a significant difference. So I\'m starting to think that the uncertainty in the optimum height is constraint by uncertainties in the measurements of the parameters rather than in our approach possibly being non-optimal.
  [/li]
  [li]My optimized thrust (obtained from aiming for v = v_t) equals 2+a/g, and not 2+2*a/g. Currently I\'m not sure why, but when I try to reach 2+2*a/g I just go with max thrust all the time, because it\'s always above the max thrust limit.[/li]
  

[Kosmo-not]

Excellent. What did you use to do that? MATLAB?

[Iskierka]

@izkierka - I would suggest throttle steps of 10% to speed up your heroic iterative process, then you can refine within those steps once you are close to optimum.

For now, I\'ve dropped the iterative solving, due to the differing solution. I\'m going to try correctly calibrate the numbers with the correct forces now added, but as jebbe noted, there is an extreme sensitivity to initial conditions and fundamental constants - a change of 0.01% in the surface-level atmospheric density alters the final altitude by several metres, and unless horizontal coriolis acceleration has a much greater effect than you would expect, adding under 10% to what is already a very small effect, KSP does not actually allow full throttle (attempted full-throttle reference launches consistently get 100-400 m higher than the simulation.)

As a fun reference, the simulation currently thinks the limit is 2-3 m above the current record - get cracking on raising the bar, already! (it\'s probably a bit higher than this due to inefficient on/off throttling to maintain velocity and still more to add to the sim itself. If anyone can think of a good alternative way to very, very precisely determine atmospheric density, surface velocity, and Kerbin\'s gravitational parameter, this information will be appreciated.)

[Kosmo-not]

Density was determined by doing a fall test through the atmosphere. Best estimate of the density equation is 0.01*exp(-altitude/5000).

Surface velocity is your velocity indicator while in surface mode. It can be switched between surface and orbit modes by clicking on it.

The gravitational parameter can be measured by the time it takes to complete an orbit.

[closette]

@jebbe - very nice work, and one heck of a lot of info in one graph. And C++ code that I can actually follow - you made my day!

Yes there must be some sensitivity to assumed parameters - for one thing the terminal speed model may be off by a few m/s at each altitude. And please bear in mind that +/-40 m at 33400 m is only 0.12 percent!

Your other finding, that the experimental optimal TWR= 2 + a/g, is also what I found even though the calculus suggests TWR=2+2a/g for maximum height gained per kg of fuel. I can\'t reconcile those results (except in the case where a=0 in a v_T=constant slab of course).

The problem I have comes from Newton\'s 2nd law, which when factored (see my PDF) becomes (a/g) = TWR - 1 -(v/v_T)².

Plugging in TWR=2 + 2(a/g) gives a strange result. TWR=2+(a/g) makes more sense - the thrust opposes equal contributions from drag and weight and has just enough extra to accelerate to keep up with the increasing terminal speed.

Not sure how to resolve it, but at least I\'m not alone!

[Iskierka]

I have that much very easily. I\'m attempting to get much, much more precise. Surface density currently being used is 0.0102095, and a change of just 0.0000001 alters results by metres. Surface velocity is estimated at 174.55 m/s, but could vary significantly; gravitational parameter needs least precision adding, but any that could would be helpful.

TWR = 2 + a/g is an interesting suggestion which I will ask the sim to try shortly, and see where it ends up - at the very least, it could be helpful as a dynamic, more efficient target than the on/off currently used when estimating maximum.

[Zephram Kerman]

@Zephram,

The chart is very useful, and thank you for taking the time to make it (with video capture, presumably).

Yes. I replayed the slide show and used frame advance to find the speeds close to each benchmark altitude. Then Excel is nice for quick and dirty graphs like this.

After a few more fails, I\'m starting to intuitively suspect the stronger influence is going too fast early on. Later in the flight, deviations from the profile seem to matter less. Also, going a little too slow early on actually rewarded me with another 14 m! So I\'m up to 33,437 m now.

[jebbe]

@iskierka

How exactly are you doing your simulation? I\'ve tried Monte Carlo (randomly changing the thrust) and brute force (try \'all possible\' thrust profiles - meaning a discretized subset of them), but Monte Carlo didn\'t converge, and the brute force took way too much computing time for a halfway well resolved thrust. But it seems as if you can get your brute force to work - how do you do it? From some of your posts I take it that you go with on/off only - that\'s enough to get this high? Great job I\'d say!

Oh, and how do you trim your parameters? Or, which of the parameters do you trim, and which ones do you take as given? I\'ve found that one has way to many possibilites to tweak stuff to deduce anything about the actual parameters in the game with the necessary precision.

@closette

I tried to derive the TWR=2+a/g once more, but I also arrive at 2+2*a/g, using your definition of efficiency. We must be missing something here...

About the code: Glad you can understand it! I thought about properly encapsulating everything in a class, but then I felt too lazy. All the c++-programmers out there, please don\'t judge me by this.

Oh, and I\'ve been able to squeeze out another three meters, I\'m at 33483m in the game. Unfortunately, that doesn\'t get me back to third...

[closette]

I thought about properly encapsulating everything in a class, but then I felt too lazy. All the c++-programmers out there, please don\'t judge me by this.

Readable code that works without using unnecessary object-oriented constructs that only serve to obfuscate and confuse? C++ programmers out there take note!

[PakledHostage]

@iskierka

Oh, and how do you trim your parameters? Or, which of the parameters do you trim, and which ones do you take as given? I\'ve found that one has way to many possibilites to tweak stuff to deduce anything about the actual parameters in the game with the necessary precision.

I\'m puzzled by that too, Iskierka. Based on this post, it sounds like you\'ve tuned your model to a flight test where you had the throttle set at 50%. But how do you know that the throttle was set precisely to 50% during that test flight? Is there a precision throttle setting readout somewhere in the game? Further along, this post suggests that your model is out by 100-400 m when you compare its results to a full throttle test flight. An imprecision of as little as ±1% in your throttle setting during the 50% throttle 'tuning test' could easily account for that 100-400 m error. (For example, my spreadsheet predicts ±1% variation in throttle about the 50% setting results in about ±75m variation in apoapsis for this spacecraft configuration).

It would help us all out greatly if you could provide more details about your method. Could you maybe provide a table showing how well your current model correlates to the in-game physics? It would help us understand how robust your model is to variations in the basic paramaters, and will allow us to interpret the validity of your results when you attempt to account for the more subtle effects.

[Iskierka]

The 50% was done by pressing 'launch' and not touching the controls after - since throttle starts at 50%. It can also be confirmed with a joystick with a very large deadzone set (in KSP\'s options, as KSP ignores directInput settings), to ensure that the throttle is settled in that area. Unfortunately, as these are the only ways to be certain of exact throttles, only 0%, 50%, and 100% can be done, and 100% can\'t yet be reconciled. (Though there are one or two aspects of the Coriolis effect to be implemented yet, and lateral drag at high altitudes may be making a difference).

Regardless, the confirmed data points found:

50% throttle: Simulation gets 31991.0 m at current tuning. KSP gets either 31991 or 31992m.

100% throttle: Simulation gets 22597.8m. KSP gets 22647m. (Definitely different result.)

Initial conditions of rocket are +64m altitude (appears to be where the rocket sits while on the pad), 0 m/s vertical velocity, and aforementioned other conditions. To tune, I adjust a number until it can match the 50% launch as closely as possible, as I\'m more confident of that result, then compare the other numbers.

As for 'calculating the optimal' - either I do a once-through test in which the engine thrusts at either 100% or 20%, depending on whether it is above or below terminal velocity, or I do a brute-force method where, rather than trying random patterns, or trying -all- patterns, I start the rocket off with a simple pattern (usually all 100%) and see where it gets to. Then, at each timestep, I go through all the possible variations, and before moving on to the next timestep, select which one gave the best final result. After a few passes, this should find the optimal thrust pattern, having considered, effectively, all patterns, but without having had to try the silly ones, such as all-0%, as 0% thrust was never optimal.

PS. And a thought on 2 + a/g - it\'s quite possible this is simply emergent. If you think backwards, this means T*g = 2g + a ... or, in other words, the thrust we\'re outputting is equal to our losses (which, following terminal velocity, are 2g) plus our acceleration. However, there is no reverse connection: nothing mathematically to say if you follow T = 2 + a/g at each point, you will follow an optimal ascent. You might, but the correlation was emergent, not inherent.

[Kosmo-not]

Why not just calculate the throttle needed to achieve the velocity where F_g = F_D in the next time step? It sounds like that\'s what you\'re trying to find with your method.

[BillWiskins]

Lordy, I do wish I could speak Science. Anyway, I did the challenge, and came up a couple of hundred (okay a thousand) metres short. Trying to understand all the terms and equations being flapped about in here is actually more fun than trying a slightly different throttle plan....

Anyway, guess it\'s not so much of a \'mini\' challenge anymore, right?

[closette]

Hi Bill,

I don\'t think anyone on this thread has all the answers to the fuel efficiency problem, least of all me, but I am glad you gave it a go. To get closer to the record altitudes you could start trying to follow the velocity vs. altitude profile in this earlier post:

http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg106460#msg106460

and refine your throttle up/down technique from there. Good luck!

[jebbe]

Anyway, guess it\'s not so much of a \'mini\' challenge anymore, right?

That\'s so true - I\'ve probably spent more time on this thread than on trying to get Kerbals to the mun.

Oh, and I managed to get to second place: 33495m.

There\'s a funny thing about this though - my impression is that you get higher with a lower screen resolution. If this is true, it seems that the time step used in the numerics depends on the frame rate within the game, because smaller time steps could actually bring you to greater heights: in an explicit first order time stepping scheme, you use the velocity of the beginning of each time step for the whole time step, so for finite time steps you are always going a little slower than you actually should while accelerating. After burnout, it would be the other way round, so in a wild guess I would expect higher altitudes if you use crappy graphics settings on a fast computer and time warp after burnout.

edit: Some experimentation with my numerical code does indeed show a significant impact of the time step - for a time step of one second I get about 200m less than for a really tiny time step. For anything better than 0.1s I just get randomly scattered values of about +-20m around the max height.

[jebbe]

I\'ve been pondering about the impact of screen resolution and time warp on the maximum height, so I\'ve done some tests: I\'ve launched three different craft over and over again at full throttle and recorded their maximum altitudes. This gave some strange results: for each craft, I always get one out of two values, so each craft will either reach altitude A or altitude B. I\'m not yet entirely sure when I get how high, and somebody else will probably have to confirm this, but it seems that time warping is the key here, although in a strange manner: It seems that if at some point in the past you have used time warp in the game, you get one altitude, and if you haven\'t, you get the other one. Going back to the VAB seems to reset this, but just hitting relaunch does not.

When I tried this challenge over and over again it didn\'t get me anywhere, but then trying again later I got to second place at the first try - this is probably why.

Unlike assumed previously, the screen resolution does not seem to play a role.

These were the rockets I launched and the two distinct recorded altitudes:

Pod - ASAS - SRB:

6336m

6320m

Pod - ASAS - LFT - 200-thrust-engine:

41488m

41468m

Pod - ASAS - LFT - gimballing engine:

44383m

44433m

Together with closette I\'ve been working further on the c++-code, and using a 4th order Runge-Kutta (RK4) method we seem to be able to eliminate the influence of the time step: I think that with an adequate time stepping (20ms or less) the numerical procedure should be stable and accurate up to centimeters or even better in the final height.

So I\'ve used this code and tried to match the recorded altitudes, adjusting only the scaling parameter of the density function. By doing this, I do of course assume that all other parameters are correct, and I\'m aware that this might not be the case. Anyway, for the two liquid fueled craft, I get these two density laws, which give the correct altitudes for both vehicles, give or take 10m:

0.009728 * exp(-h/5000.0);

0.009721 * exp(-h/5000.0);

For the solid boostered craft, I don\'t get this close, but that might be due to the specific impulse: the wiki gives 2257 for it, but using some more digits could help here I think.

I do realize that the time warping does probably not influence the atmospheric density but rather some numerical feature like e.g. the time step, but since we don\'t know what solution method KSP (or rather unity) is using, this seems to be the only parameter we don\'t have some previous knowledge about, so it\'s the only one left to adjust. Not nice, but the best I can think of right now.

Now, with some more work on the optimizer for this challenge (using the RK4 scheme and Newton iterations to really get the thrust right and get exactly to the terminal velocity whenever possible), I plugged these density laws back in and got 33481.3m and 33513.0m. These values are actually very close to the heights from our leader board, matching them within the estimated error margin of 10m!

For those interested, I have attached the code for full throttle ascent (fullthrottle-RK4.cpp) and the new optimizer for the challenge (goddard-rk4-newton.cpp). Once again, I can\'t stress enough the contributions of closette in improving this code!

[Iskierka]

I have to ask; does your code account for coriolis effects on the craft? In my initial testing I was able to match with a density below 0.01, but then when accounting for such, due to the differences in the result, I found the density going above. I still haven\'t completely matched the results, but there are more fine details to add in. And with 1 ms stepping I seem to see little randomness even with simple step calculations.

Additionally, things like the starting altitude (0m versus the listed 64m) do seem to have significant impact.

[jebbe]

I have to ask; does your code account for coriolis effects on the craft? In my initial testing I was able to match with a density below 0.01, but then when accounting for such, due to the differences in the result, I found the density going above. I still haven\'t completely matched the results, but there are more fine details to add in.

No, I don\'t account for that. I might be wrong, but shouldn\'t it be zero anyway, since we launch from the equator?

edit: I didn\'t really think that through, got confused with wheather patterns, which move parallel to the surface, as opposed to our vertical launches.

What could matter though is the centrifugal force due to Kerbin\'s rotation - I haven\'t really thought about that yet.

So how exactly would you account for the Coriolis force?

And with 1 ms stepping I seem to see little randomness even with simple step calculations.

Additionally, things like the starting altitude (0m versus the listed 64m) do seem to have significant impact.

You are getting good convergence with a first order scheme? What data type are you using as your floating point values? Using the 80bit extended precision types of the x86 floating point unit (I think that\'s what long double in c++ translates to), I still get a huge impact on the time step, especially in the first order scheme: my results scatter by about 20m depending on the time step, and don\'t really converge. In fact, too small time steps actually increase the error, I would think because of accumulating round offs. In a second order scheme with time steps of 1ms, closette still got an error of more than a meter, so I think there is good reason for the fourth order scheme... Or am I missing something?

Yes, the starting altitude does have quite an impact, I was surprised to see just how much, actually.

What kind of code are you working on? I\'d love to see more details!

[Kosmo-not]

In my opinion, since the velocity vector is vertical (or nearly so) relative to the surface, the coriolis effect is negligible when it comes to computing drag.

[PakledHostage]

In my opinion, since the velocity vector is vertical (or nearly so) relative to the surface, the coriolis effect is negligible when it comes to computing drag.

I think he\'s looking at it 'from the top down', in the equatorial plane. When viewed in that 2D plane, the spacecraft launches outward from the edge of the rotating disk.

Even so, the effect is small. The highest speed that I\'ve ever seen while attempting this challenge is about 590 m/s. By the calculation below, the coriolis acceleration at that instant would be only 0.035 g.