Optimal Staging Algorithm

[Wcmille]

Hey there, I wanted to work on my own designer for optimal stages.

Anybody know of the algorithm to calculate optimum fuel sizes for a given payload, engine weight, and Isp?

 

I'm aware of Optimal Rocket Calculator, which doesn't handle NERV or DAWN engines. It also doesn't handle drop tanks. I think Optimal Rocket Calculator also uses brute force.

[steuben]

Don't knock brute force. It will complete any job you can think of. 

As for optimum... I think that may be a pretty situational thing. Different ships for different uses will have different optimums.

[GoSlash27]

Wcmille,
 I've written a couple tutorials on mathematically optimizing stages based on payload mass, required DV, and minimum t/w.

Is that what you're looking for?

 

Best,
-Slashy

Edited November 26, 2017 by GoSlash27

[Wcmille]

@GoSlash27 

Does your spreadsheet assume always 4 stages?

 

 

Here's an example of the class of problem I'm trying to solve:

Build the lightest-weight chemical rocket (no ion) possible to send 10 tons of payload 18,000 dV. (any number of stages)

[GoSlash27]

wcmille,

 No, my process is for optimizing a single stage only. It wouldn't tell you exactly how many stages to employ.

Best,
-Slashy

[GoSlash27]

Wcmille,
 I poked around on my spreadsheet to find the optimal staging point for LV-Ns in series, assuming a 0.5g minimum acceleration. It worked out to 6,600 m/sec DV.

 A simple series LV-N would therefore be a 3-stager, with 6km/sec DV per stage.

Stage 3: Payload= 10t. Mt= 74.9t Neng=6
Stage 2: Payload= 74.9t. Mt= 522t Neng=40
Stage 1: Payload= 522t. Mt= 3,640t Neng=279

Since my process only evaluates a single stage pushing an inert payload, it is incapable of modeling parallel staging, drop tanks, or asparagus. These schemes are more efficient than series staging, so they should be able to get you a smaller rocket.
 

To model that, you will have to work the rocket equation the normal way and employ successive iteration.

Best,
-Slashy

[septemberWaves]

If there was a single simple algorithm for designing optimized rockets, rocket science would not be so hard.

The "best" rocket for a given situation is arguably the one which provides exactly enough delta-v for the payload and mission requirements with minimum waste, and is the cheapest option for this. That's monstrously difficult to create a step-by-step process for the designing of, because there are just too many variables. Variables include the width of the rocket stages (because of drag), the width of the payload fairing if there is one (also because of drag), the overall mass of the complete rocket both including and not including payload (and the difference between wet mass and dry mass is also significant), what kind of staging methods are available (e.g. drop tanks, half-stage, asparagus staging, parallel boosters, etc), what kind of engines are available (which will also influence how vertical staging works because if hot staging is used the decoupler will have to be open like the ones on the N1), what materials are available for making the tanks, the mass of avionics equipment required, etc. And you'd have to run through all of these variables every single time you change the rocket design to see how the changes you make affect the final efficiency, cost, and delta-v. You can ignore some of these variables in KSP, but not many of them.

EDIT: the launch profile also has a significant effect on how you optimize a rocket. Different launch profiles have different thrust requirements at different times, and also have different effects on drag. A launch profile which is steeper than average, for example, will suffer less overall drag but ultimately will usually require more fuel to reach orbit because it will need to expend more propellant to go sideways. So even with an identical rocket, a steeper launch profile usually means a lower payload. But you also can't use a launch profile which isn't steep enough because otherwise the drag makes it impractical, your rocket becomes susceptible to flipping, and you need far more thrust overall.

Edited November 26, 2017 by eloquentJane

[wumpus]

As far as I know, "brute force" is the only way this problem has ever been solved.  There might be trivial cases where local maxima can be found and an optimal solution found, but each part will create a new function that still requires "brute forcing".  Note that is still true after ignoring both gravity losses and aero losses.  A brute force method that considers such possibilities may well be more efficient than an "optimal" one that doesn't.

Ions and  NERV are trivial to optimize.  If in a vacuum and in at least a stable orbit (you don't require thrust to avoid falling into a gravity well) Ion>>NERV>>everything else  (for mass/cost efficiency.  Not remotely efficient for player time*).  Consider mech jeb, kerbal alarm clock, and finally KOS before using these systems.  In practice Ion powered ships are expected to spiral out (no Obereth) while NERV ships often use the Mangalyaan maneuver (often called "Pe kicking" in KSP) to use the Obereth effect with low TWR.  The differences mean that these engines need more delta-v than a "subway map" might indicate (the NERV might be close, but you will always have to do your final burn of more delta-v than delta-v_{total needed} - delta-v_{escape velocity (for you SOI)}.

Drop tanks are unlikely to be added to this system as the obvious solution (for mass) is that all tanks are as small as possible, only two (or possibly one if you can afford to twist around and eject it off the top) tanks are used and dropped immediately when empty.  Creating a structure that can utilize such a design is non-trivial.

Slashy's answer is the best you will find in KSP.  Also don't expect things to always neatly break into stages, although one favorite trick is to put drop tanks on top of solid boosters so that once they drop you have a full "1.5th stage".

* ions may look "overpowered".  Compared to reality, they are *underpowered* (the ISP is higher).  The catch is that they have even less thrust in reality, which doesn't really matter as presumably NASA has somebody at JPL tasked with making sure it is still doing its thing [actually what I've heard it is more "somebody gets a few hours of time on the deep space network and has to resolve all possible issues in that narrow timeframe.  Only steely eyed missilemen with deep experience need apply.]

 

[GoSlash27]

3 minutes ago, wumpus said:

If in a vacuum and in at least a stable orbit (you don't require thrust to avoid falling into a gravity well) Ion>>NERV>>everything else  (for mass/cost efficiency.  Not remotely efficient for player time*).

Wumpus,
 While this is certainly true for high DV burns, it isn't necessarily true for short ones. For trips under 2km/sec or so, chemical rockets can actually come up lighter than nukes or ions. 2km/sec DV can get you to a lot of places if you spend it wisely. For many longer trips, chemical stages remain cheaper even though they're heavier.
 Of course, this doesn't apply to what Wcmille is talking about.

 Best,
-Slashy

[GoSlash27]

Modeling an all- nuke asparagus arrangement by hand with the above constraints leads me to 1,192 tonnes. I wonder if going to chemical outside the nuke cluster would reduce the overall mass... but not so much that I want to chase the math to find out

Best,
-Slashy

[wumpus]

1 hour ago, GoSlash27 said:

Wumpus,
 While this is certainly true for high DV burns, it isn't necessarily true for short ones. For trips under 2km/sec or so, chemical rockets can actually come up lighter than nukes or ions. 2km/sec DV can get you to a lot of places if you spend it wisely. For many longer trips, chemical stages remain cheaper even though they're heavier.
 Of course, this doesn't apply to what Wcmille is talking about.

 Best,
-Slashy

I'm sure I can build a payload to justify the ions (not the time to put it in place), but the NERV is pretty massive, so is less suitable for jutting to Mun/Minmus.

On the other hand a NERV-based shuttle for use around Kerbin's SOI is quite useful.  This is true even for ships that weren't intended for such duty.  As long as they have a NERV engine, a docking port, and aren't erased they will do fine (you can do the same with Poodles, but it is harder to justify unless your launcher is a spaceplane).

[GoSlash27]

27 minutes ago, wumpus said:

I'm sure I can build a payload to justify the ions (not the time to put it in place), but the NERV is pretty massive, so is less suitable for jutting to Mun/Minmus.

On the other hand a NERV-based shuttle for use around Kerbin's SOI is quite useful.  This is true even for ships that weren't intended for such duty.  As long as they have a NERV engine, a docking port, and aren't erased they will do fine (you can do the same with Poodles, but it is harder to justify unless your launcher is a spaceplane).

wumpus,

 I'm not arguing any of that. I'm just pointing out that, all else being equal, nukes and ions won't always work out lighter and cheaper than chemical rockets. This only holds true for high DV burns.

For example, directly comparing the LV-909 to the LV-N at 10t payload and 0.5g minimum acceleration shows the LV-909 is lighter at 1,746 m/sec DV or less and remains cheaper (although heavier) throughout the LV-N's entire staging envelope.

Best,
-Slashy
 

Edited November 26, 2017 by GoSlash27

[Wcmille]

6 hours ago, wumpus said:

As far as I know, "brute force" is the only way this problem has ever been solved.  There might be trivial cases where local maxima can be found and an optimal solution found, but each part will create a new function that still requires "brute forcing".  Note that is still true after ignoring both gravity losses and aero losses.  A brute force method that considers such possibilities may well be more efficient than an "optimal" one that doesn't.

Ions and  NERV are trivial to optimize.  If in a vacuum and in at least a stable orbit (you don't require thrust to avoid falling into a gravity well) Ion>>NERV>>everything else  (for mass/cost efficiency.  Not remotely efficient for player time*).  Consider mech jeb, kerbal alarm clock, and finally KOS before using these systems.  In practice Ion powered ships are expected to spiral out (no Obereth) while NERV ships often use the Mangalyaan maneuver (often called "Pe kicking" in KSP) to use the Obereth effect with low TWR.  The differences mean that these engines need more delta-v than a "subway map" might indicate (the NERV might be close, but you will always have to do your final burn of more delta-v than delta-v_{total needed} - delta-v_{escape velocity (for you SOI)}.

Drop tanks are unlikely to be added to this system as the obvious solution (for mass) is that all tanks are as small as possible, only two (or possibly one if you can afford to twist around and eject it off the top) tanks are used and dropped immediately when empty.  Creating a structure that can utilize such a design is non-trivial.

Slashy's answer is the best you will find in KSP.  Also don't expect things to always neatly break into stages, although one favorite trick is to put drop tanks on top of solid boosters so that once they drop you have a full "1.5th stage".

* ions may look "overpowered".  Compared to reality, they are *underpowered* (the ISP is higher).  The catch is that they have even less thrust in reality, which doesn't really matter as presumably NASA has somebody at JPL tasked with making sure it is still doing its thing [actually what I've heard it is more "somebody gets a few hours of time on the deep space network and has to resolve all possible issues in that narrow timeframe.  Only steely eyed missilemen with deep experience need apply.]

 

Yes, I find departing from Mun to be tremendously helpful in saving dV. You can get about +600 dV for a high-speed maneuver by "dropping" from Mun. 

Drop tanks often improve dV, cost, and mass at the price of thrust. I find them to be most helpful on the heaviest stage

Here are links that suggest a mathematical solution is possible:
https://mikegrudic.wordpress.com/2017/06/02/optimal-rocket-staging/
https://rocketsim.wordpress.com/2017/05/07/performance-and-optimization-multi-stage-rockets/

 

[GoSlash27]

1 hour ago, Wcmille said:

Here are links that suggest a mathematical solution is possible:
https://mikegrudic.wordpress.com/2017/06/02/optimal-rocket-staging/
https://rocketsim.wordpress.com/2017/05/07/performance-and-optimization-multi-stage-rockets/

Wcmille,

 Unfortunately, those only apply to serial staging.

Best,
-Slashy

[Wcmille]

4 hours ago, GoSlash27 said:

Wcmille,

 Unfortunately, those only apply to serial staging.

Best,
-Slashy

Not sure what you mean by serial? As opposed to asparagus?

I'd think any high dV rocket would be using a single NERV (or DAWN).

[GoSlash27]

Wcmille,

"Serial" as in one stage accelerates with the next stage as payload. It gets more complicated with parallel, drop tanks, and asparagus. The same formulae do not apply in those situations.

Best,
-Slashy

[magnemoe]

On 26.11.2017 at 12:56 AM, steuben said:

Don't knock brute force. It will complete any job you can think of. 

As for optimum... I think that may be a pretty situational thing. Different ships for different uses will have different optimums.

This, one issue I tend to run into then launching something with an oversize fairing is that i have to keep the long first stage up to 35-40 km, dropping first and continue with second stage earlier would be more efficient however the small second stage would not be aerodynamic stable. Solution tend to use first stage longer, perhaps add SRB to it then shrink second stage and probably put inside fairing. 

[OhioBob]

On ‎11‎/‎25‎/‎2017 at 6:20 PM, Wcmille said:

Hey there, I wanted to work on my own designer for optimal stages.

Anybody know of the algorithm to calculate optimum fuel sizes for a given payload, engine weight, and Isp?

For getting to orbit I use a very simple rule of thumb that works nicely.  Using two liquid fuel stages, the second stage (upper stage) should contain a mass of propellant equal to the mass of the payload, where the "payload" is everything that sits on top of the second stage (including fairings, decouplers, etc.).  And the first stage (lower stage) should contain a mass of propellant twice the mass of the payload, or twice the mass of propellant in the upper stage.

Any additional stages, such as required for an ejection burn, are designed as part of the payload.  Requirements for those can vary widely depending on the mission.

[Wcmille]

Here's a paper that I think is what I'm looking for, but the notation confuses me a bit. Looking to convert the solution to an algorithm.

http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=AD0607412

[Corona688]

On 11/25/2017 at 5:20 PM, Wcmille said:

Hey there, I wanted to work on my own designer for optimal stages.

Anybody know of the algorithm to calculate optimum fuel sizes for a given payload, engine weight, and Isp?

It's usually done the other way around:  "We know how to reach orbit:  600 m/s at 1.5 gees(40 seconds), then 600 m/s at 0.9 gees(68 seconds), then 1500 m/s at 0.5 g(305 seconds).  Engines weigh such-and-such per kilonewton and all have an ISP of 340."  Then Werner von Braum breaks out the slide rule and tells you the facts of life.  Then you curl up and cry and cut down the payload by a factor of three.  Finally the requirements for your imaginary engines get given to RocketDyne, and they curl up and cry.

You could make template rockets that way - this many mainsails plus this many thuds with this much fuel for the bottom stage, then this many skippers plus this many thuds for the middle stage, then this many thuds for the top stage.  It probably won't be able to put them all together for you, unless you stick to a template there too.  Relying on thuds helps prevent impossible design suggestions.

Edited December 20, 2017 by Corona688

[Wcmille]

I had a breakthrough I wanted to share.

Here's my current algorithm:

1. Create a list of all reasonable engine combinations for the number of stages specified.
2. Add a small amount of fuel to the stage which will benefit the most from the fuel, without going over the TWR limits.
3. If all stages can no longer have fuel added due to TWR limits, the design is a failure.
4. Report all successful designs.

I used to calculate the best stage by looking at the incremental dV for each stage like this:

F = mass of fuel modules, including the fuel and the leftover dry mass.
s = the dry weight of all the other stuff which is not fuel (engine, payload, etc)
r = The wet to dry ratio of fuel tanks, which is usually 1/9 in KSP.

dV = 9.81 * Isp * ln (wet/dry) = 9.81 * Isp * ln ((s+F)/(s+rF))

Gravity cancels out across all the stages, so we're left with this for the incremental dV for each stage:

d/dF Isp * ln((s+F)/(s+rF)) = Isp * (s-rs)/((s+F)(s+rF))

This *almost* works, but doesn't account for higher stages removing dV from lower stages. I realized that we can subtract away the loss of dV from other stages by taking a partial differential of dry mass instead of fuel! That looks like this:

d/ds Isp * ln((s+F)/(s+rF)) = Isp * ((r-1)*F)/((s+F)(s+rF))

So when you are looking for which stage to add fuel to, the full calculation for each stage is the incremental gain minus the incremental loss for all stages beneath it.

Instead of incrementally adding fuel, I need to use the Newton-Rhapson method to solve these simultaneous non-linear equations, but I'm still (re)learning how to do that.