Mini-challenge: max altitude with this supplied spacecraft

[Kosmo-not]

Here is a chart displaying the instantaneous efficiency (or fuel economy) of various thrust profiles.

I would have included a 300 constant thrust profile in there as well, but the differences between it and the optimal profile are hard to see.

[PakledHostage]

I\'ll give it a try when I next get a chance to play the game. I might not get that chance until tomorrow evening though. I\'ll post back with my results.

Here\'s my best effort so far... Not quite good enough for third place. Two metres shy!

[Iskierka]

I\'m not convinced of the assumption that v/T being the efficiency factor is most appropriate, but working with that, you have assumed that a << g is true for the majority case, so far as I can tell, which it isn\'t: substituting back, I arrive at an equation x = (2 - 2/g - (2*v^2)/(g*v_t^2) ) / (1 - 2/g), which solves at liftoff ( v = 0, g = 9.8 ) for x ~= 2.25, and at roughly 60-70 km, x ~= 2.33 (due to reducing g and arbitrarily high v_t), both of which are slightly (but noticeably) above the assumption of 2, which only holds true when v = v_t, or more usefully, when close to max-q, assuming max-q is a high value.

Interestingly, the space shuttle acceleration profile appears close to this just-above-2 practice, for the most part, with the biggest exception being the final acceleration when losses are negligible and they want to leave the tank in a lower orbit. While the Saturn V is quite clearly faster accelerating, a quick search finds a mention on the Saturn V\'s Wikipedia article that strongly implies the F-1 engines are non-throttleable; further confirmation from other sources, if it could be found, would say that it therefore is not useful for judging optimal ascent trajectories.

[closette]

substituting back, I arrive at an equation x = (2 - 2/g - (2*v^2)/(g*vt^2) ) / (1 - 2/g),...

Would you mind showing us how you arrived at this equation? (Formatting is a pain, so you could just attach an image of a handwritten version if faster). Terms like '2/g' have units, so something is missing from the right side since x is dimensionless.

The a <<g assumption works up to about 8000 m, but the 'chasing terminal velocity' method/strategy/algorithm works for all altitudes.

Looking forward to reading your derivation - I spent a long time puzzling over these equations.

[Iskierka]

I\'ve noticed an error which resulted in that extra /g term, which results in the equation actually simplifying to just x = 2 v^2 / v_t^2. This looks erroroneous, but explains an oddity I was noticing, which is that when calculated for manually-set thrusts, e always peaked for thrust = 0. Always; doesn\'t matter if v >, =, or < v_t, and is as independent of a as possible for an equation which involves it.

The specific substitution used is just before the final equation used to derive the peak of e being at x = 2 + 2a/g, of a/g = x - 1 - v^2 / v_t^2. (This after re-substituting v = Wex, for simplicity.) When rearranged that arrives at the first equation in this post. What I would take this to mean is that the initial assumption of measuring efficiency as e = v/T is probably wrong, as quite clearly once you\'re moving it\'s most efficient not to thrust more, when looking at it intuitively.

Also, while yes, in theory having 2/g would put units in the left-hand-side, this is computing; effectively, all variables are fundamentally unitless. (or the computer just doesn\'t care about them.) The programmer can happily multiply acceleration in a given frame by a random planet\'s mass, divide by another\'s gravitational parameter, and then add the acceleration due to gravity of a third, and the only complaint it might have is if for some reason one planet had a gravitational parameter of zero (or mass of infinity, or either of NaN). While holding the unit assumptions is usually useful, there is no reason for it to be true in computing, and it cannot be taken as an axiom.

[boolybooly]

Thanks for calculating the list of target speeds per altitude Closette, I will try flying them later and see if it helps, they are close to the speeds I was using, though a bit lower in the middle part of the ascent.

The optimal speed per atmosphere density is how I was thinking of it, it is a practical way to guide a flight as there is no readout for throttle setting or TWR so I think you have improved our flight technology here!

The principles explored in this thread are useful for pilots maximising lift off fuel efficiency for high TWR capable craft. In practice I did do a couple of experiments a while back and realised that this phenomenon existed but did not nail the specifics, I just built my craft so that their acceleration curve was a bit lower. But now we have an optimal curve to shoot for! So that is useful for ship building as well, if we build them right they should fly themselves.

So its a worthwhile thread and very educational

[jebbe]

@closette,

I think you are right, the TWR=2-approximation should be pretty close to optimal. However, you still assume that the acceleration is small, and that g is constant, right? Especially the non-constant g could be of some importance, although I think that in the limits of what we can do with the controls in the game the actual difference should be quite small.

I don\'t have the time to look into the details right now, but I\'ll try to think about the non-constant g in the next couple of days.

[Iskierka]

The issue currently being faced is to re-do the calculation of optimal with a correct interpretation of what is efficient; ie, a different definition of e. In this case, since we are launching vertically the whole way and then finishing with a ballistic arc, I think what\'s needed is a definition of a ballistic arc in a rectilinear (minimal sideways motion) situation with varying rho, calculating the peak point that will be attained from any given final velocity and altitude. From this, e can be properly defined, and optimising it can be calculated anew.

Meanwhile, after speaking with my spacecraft flight lecturer and getting told, in short, 'the calculus way is ... \'difficult\',' I\'m going to attempt the preferred method of brute-force, simulate via scripting for as many thrust profiles as possible, and see what achieved the optimum. Then see if that can be reverse-engineered to a workable equation.

EDIT: While I am going to work on the latter solution, I have just found a very interesting solution for if a simple dragless ballistic arc is considered; u^2 = v^2 - 2as being considered, the solution for highest peak with unchanging gravity is s = u^2/2g (taking g as cancelling the original negative). By taking e as a factor that optimises this with respect to fuel spent, I have an interesting situation where above one value of u, optimal reduces with increasing thrust, and below, increases. There will have to be further experimentation into this method (and a better equation for the ballistics).

EDIT[2]: More testing revealed the pattern is not as simple as first thought, however it is definitely more interesting than the previous results.

[boolybooly]

OK following the flight plan first I equalled PackledHostage.

EDIT

And then I improved on that by 1 meter

33479m woot!

[Zephram Kerman]

First of all, many thanks for this! I\'ve been trying to catch up reading this thread for the past three days. Now I\'m finally ready to attempt the challenge; hopefully this evening after work. It is doubtful I can beat the top performers, but I think it\'s a good idea to repeat an experiment several times for confirmation.

I too have learned a lot reading this thread. In fact, I consider these things therapeutic! While some of this math admittedly goes over my head, the rest of it was once understandable. Reading threads like this helps to knock off some of the moss and rust from my brain. ???

v_T ~ 97.3 exp(+altitude / 10183m), so for example:

Altitude (m) Target speed (m/s) - rounded to nearest 5 m/s

0 97.3- you\'d better get a move on!

500 105 - you should be catching up by now!

1000 110

2000 120

3000 130 - usually the first benchmark I have time to look at

5000 160

8000 215

10000 260

13000 350

15000 425

16000 470 - most of us are at least thinking about staging and pitchover maneuvers by now!

..

32000 2250 - this is equal to the orbital speed, so by now you should be pushing over hard for orbit, and air drag is not as important above this altitude.

[scribbles this on a yellow sticky, and staples it to the inside of Bill\'s visor.]

[PakledHostage]

OK following the flight plan first I equalled PackledHostage... And then I improved on that by 1 meter

33479m woot!

The gauntlet has been thrown! To the pain!

[Kosmo-not]

The thinking behind my graph of efficiency was that I would measure the fuel economy of the rocket if it were to maintain its given speed with g, rho, and m being constant. I had been trying other methods, but all of them would make either the 600 or 200 thrust profile look more efficient. I just wanted a quick way of looking at a graph and seeing which is more efficient at a given altitude.

[closette]

[scribbles this on a yellow sticky, and staples it to the inside of Bill\'s visor.]

Love that mental image! Note that the speed vs. altitude may be +/- 5 m/s from optimum, but in my last attempt to follow it as closely as possible I reached 33483 m, so it must be close.

If you look at the 'throttle' column from Kosmo-not\'s spreadsheet for this particular spacecraft, you will see there\'s a 'flat spot' where the throttle is ~ constant between 4500m and 6500m, so you get a brief rest where you should not have to touch the controls, with a slowly increasing rise thereafter. You should be at about 80% throttle at burnout for this spacecraft. (Not 100% as I had originally thought).

[closette]

@Iskierka,

By all means please keep looking at this problem - a different perspective is very welcome. I\'m not 100% happy with efficiency e=v/T either, since it blows up when thrust T is very small or zero. On real-world rockets, I understand that sometimes it is optimal for them to follow a 'coasting arc' for part of their ascent, to save fuel for later when there will be less drag.

I also found the 'junk' result that when x=2+2(a/g), plugging this back into the equation of motion gives

a/g =(v/v_T)² - 1, which makes no sense unless v >=v_T. Not sure how to resolve this, since all the arguments leading up to it seem sound.

I did try optimizing for a different quantity - the craft\'s change in mechanical energy per kg fuel used, but that gave me back the same criterion, TWR = 2 + 2(a/g). PDF attached if you\'re really interested.

On the subject of units, I don\'t want to cause distraction from these interesting topics with a polemic, but I feel compelled to give two examples (neither of which are the Mars Climate Orbiter!). In short - computers will calculate anything you want, but GIGO - Garbage In, Garbage Out.

Example 1: This is when I was a Physics TA in a class for biologists. A girl was recording distances and times of a cart on a track, and had 3 columns in her lab book labelled

'Distance (m) Time (s) Average Speed (m/s) Instantaneous speed' (this last column was blank)

As time went on, distance and time values increased, and a larger Distance in a smaller Time gave her a larger value for the speed, as expected. But at later times, her 'Average Speed' column contained negative numbers.

I asked her how she calculated 'Speed'. She replied 'Meters minus seconds, that\'s meters per second, right?'

Need I mention she was blonde? (So am I, but the resemblance ended there). If she had measured time in milliseconds all her so-called 'speeds' would have been negative!

Example 2: Bank A tells you your balance in dollars is 40. Bank B tells you your balance in cents is 90. How much money do you have? If you ignore the units, balance A + balance B = 130 (somethings). 130 cents is wrong, 130 dollars is wrong (try spending it), so the lesson is don\'t ignore the units!

Again I\'m not really looking for a discussion on 'units', but please be careful with them, and use them, if you want your results to have any relevance.

[Kosmo-not]

If you have a link to an article about coasting to save fuel, I am very interested in reading it. It will no doubt be very useful when I move on to making a spreadsheet to calculate an optimal full ascent to orbit.

[closette]

Here\'s a start: Drag law effects in the Goddard Problem:

http://www.ewp.rpi.edu/hartford/~kapust/EP/Other/References%20-%20Cited/%5B3%5D%20Tsiotras%20and%20Kelley.pdf - see Figure 9 where the thrust drops abruptly (but not to zero) twice. On the first page they also refer to an interesting 1955 article by Miele (1955) but I can\'t seem to access that one online.

I may have been wrong about coasting subarcs in the simplest version of the Goddard problem though - it appears that they are not usually called for.

And here\'s an article that deals with non-vertical trajectories: http://arxiv.org/abs/math/0703911 - looks like tough going!

[PakledHostage]

OK following the flight plan first I equalled PackledHostage... And then I improved on that by 1 meter

33479m woot!

I\'m back in the black... I\'ll leave it to the judges to determine whether it counts as 33487, 33488, or something in between.

[closette]

Good flight, Pakled - the 'Flight Results' window (shown after you\'ve crashed) shows the official height, but we\'ll give you 33487.5 m, which moves you up to 3rd place to date.

(Just like many of the best Olympic contests - all the action is in the battle for 3rd place, although I\'m sure I can be knocked out of second).

\'

Great expressions on the kamikaze Kerbals\' faces in your screenshot, too!

[Zephram Kerman]

After many attempts, the best altitude I could reach was 33,424 m. Now I am even more impressed with the winners. Congratulations, everyone!

I think my problem is probably too low thrust in the last couple of seconds before burnout. But even after several attempts with that in mind, 33,424 m was the best I could do.

I made a video, but am having trouble with YouTube.

[Iskierka]

Coasting to save fuel is news to me, also; most I was aware of was to have fuel for circularization, which is a very different reason to shut down.

For the immediate moment I\'ve stopped mathematical analysis of the problem, and am letting the brute-force algorithm have a go (after tuning the atmospheric density so a constant-thrust launch of 50% reaches the same altitude of 31908 m). Currently it thinks it can get a rocket to 33318 m with the pattern it has, but it\'s only done 1.5 cycles so far. (unfortunately, the code is very slow; only 100% reliable way is to vary the thrust at a point, then simulate the entire flight, and pick the maximum, which is somewhat slow.)

I will note, however, that asking it to hold back to its terminal velocity at all points did not produce the best result possible, it would seem; the result was a couple hundred m/s short of making the leaderboard. It\'s possible there\'s some imprecision somewhere, but it would be surprising that I could get 50% constant to within a metre and be out by a hundred metres when only getting less than 1.5 km higher.

[closette]

@Zephram - any entry above 33400 m is praiseworthy - it\'s not easy for me to get that the ship high on a regular basis (I was lucky with my entry).

@Izkierka

it would seem; the result was a couple hundred m/s short of making the leaderboard. It\'s possible there\'s some imprecision somewhere, but it would be surprising that I could get 50% constant to within a metre and be out by a hundred metres when only getting less than 1.5 km higher.

I am at a loss to understand any of this. The leader-board is for altitude in meters, not m/s. And 'I could get 50% constant to within a metre' and 'be out by a hundred meters when only getting less than 1.5km higher' seem to be comparing something to things you have not explained.

As for your iterative method, I look forward to the results, but I bet it\'s slow! Even if you have 100 time steps and 5 throttle steps, that\'s a lot of possible combinations if you treat the throttle settings independently! (The only constraint is on the impulse = total thrust*time provided by the finite amount of fuel). I would hope that you would start with Kosmo-not\'s throttle values as an initial guess because they must be close to optimum, even if they are not quite there.

[boolybooly]

good flying Packled

I tried a bit today, didnt get any better but one of these days...

[Iskierka]

Sorry, meant m, not m/s - too used to challenges always aiming to optimise m/s, since it\'s usually a given that you can leave the atmosphere. And what I meant was that I can make the simulation try thrusting at constant 50%, and have the final altitude within a metre of what it is in KSP, but when optimising it\'s out by a hundred metres, even though it\'s only getting 1.5 km higher. The iterative method hasn\'t made much, if any advance on that either. However, I think I know what\'s wrong, which is also something that wasn\'t accounted for in the old thread when using a falling body to determine atmospheric density and scale height; Coriolis effect. I\'ll add that to the calculation of g, re-calibrate atmospheric density with the 50% constant (0.009955 did seem odd ...), and then try the simple 'follow terminal velocity' again to see where it gets.

Also, that kind of low precision would be a lot faster than this! It manages several simulations per second, but it\'s currently set up to try each throttle percent between 20 and 100, pick the one with the best result, then move on by a second (up to 120 seconds of thrust, barring cutoff due to burnout. The sim then does another 60 for the ballistic arc). One full iteration through the sequence takes ... a long while. And then it has to try again to smooth out the curve.

[PakledHostage]

good flying Packled

I tried a bit today, didnt get any better but one of these days...

I got lucky.

What\'s that about the Infinite Monkey theorm?

PH.

[Saaur]

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.