Jump to content

Staging Optimally: wanna help me with math?


Recommended Posts

Math is part of the fun!

Edit: It's possible I've answered my own question (see the reply) but a second set of eyes would still be super appreciated, if it sound like a fun puzzle to solve through.

I feel so close, and yet so far... I was honestly expecting to figure out the problem while rubber-ducking this post together, but alas no such luck. Best of luck on your analysis, and thanks in advance for the help or consolations! Oh, and as a personal request, thanks for poking holes in my equations, but please don't poke a hole you're not willing to fill back in :wink:

 

0. Premise
So, we have a lifter that'll get mcraft tons to LKO, and a final unpowered reentry stage weighing mpod tons to finish the trip, and we want to maximize the amount of fun we can have in between.

By fun, I mean ΔV with a given TWRmin!

We should be able use the rocket equation to find the optimum size of each stage relative to the next (so long as we're using the same engine specs everywhere.) Let's solve for the deltaV of a specific case, and generalize from there.

20b.jpg

Yeah, that's the craft we're describing!

1. ΔV of a single stage, given masses and TWRs: 

Spoiler

We'll start with the rocket equation, and plug in values and stipulations specific to KSP to make it more convenient for our case.

ΔVstage = -g0 * Isp * ln(mempty/mfull) where

mempty = 1/9 * mtanks + mengines + mpayload      ->  (next line, substitute an equation for the fueltanks: mtanks) 
mtanks = mfullcraft - mengines - mpayload                    (everything that's not engines or payload is fuel) -> (substitute mengines, mpayload)

mempty = 1/9 * mfull + 8/9 * mengines + 8/9 * mpayload   
mengines = mfull* TWRmin/TWReng                            (Our engines must be this large to generate our min TWR)
mpayload = mfull * (mpayload/mfull) .... please take my word!  
-> (next line, substitute mengines, mpayload. Factor terms)

mempty = 1/9 * mfull + 8/9 * mfull * TWRmin/TWReng + 8/9 * mfull *( mpayload/mfull)   -> (next line, factor out mfull)

mempty = [1/9 + 8/9 * TWRmin/TWReng + 8/9* (mpayload/mfull) ] * mfull -> (next line, finally plug back in to deltaV equation from up top)

ΔVstage = -g0 * Isp * ln(  [1/9 + 8/9* TWRmin/TWReng + 8/9* (mpayload/mfull) ] * mfull / mfull   )    -> (next line, cancel the mfull)

ΔVstage = -g0 * Isp * ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpayload/mfull) )                           (Hooray!)

Great! We're not treading any new ground yet, but we can describe our deltaV in terms of known convenient variables. Let's march on.

Also, decouplers and other goodies can be accounted for alongside the engines in a similar way, but we'll neglect them for now.

image.png

Y axis: DeltaV for this stage in m/s. X axis: mass ratio of this stage's payload to its full mass (unitless).


We see 2000 m/s deltaV for a TWR=2 terrier stage that's 2.75 times bigger than its payload -> Sounds reasonable! This number will later turn out later to be our optimal stage ratio given our TWRs, and I may have fudged the TWRs a bit to make it to work out to about e just for the heck of it.

 

 

2. Extend ΔV from individual stages to a full craft

Spoiler

We'll bring in new equations for how multiple stages scale in deltaV and mass and use them to calculate deltaV for an entire craft worth of stages.

Posit: Stages will be geometrically scaled when optimally sized, and thus with uniform ΔVstage

(mpayload/mfull) ^ Numstages = (mpod/mcraft)    (In other words, the mass ratio of each stage multiplied together enough times will equal the mass ratio of our full craft)

ΔVcraft = Numstages * ΔVstage                              (Eq. 2) Yep, namin' this one. Just this one :D

Reorganizing the top equation gives
(mpayload/mfull) = (mpod/mcraft)
^ (1/Numstages)    -> (next line, plugging this into the ΔVstage equation and that into Eq. 2)

ΔVcraft = - g0 * Isp Numstages ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpod/mcraft) ^ (1/Numstages) )   

Neat, now we can extend our equation to a full craft. By plotting ΔVcraft while varying Numstages we can visually determine the optimal number of stages!

image.png
Y axis: DeltaV for craft in m/s -> ΔVcraft   ...   X axis, the number of stages in this craft -> Numstages.
The craft was declared to have a final pod of mass 1ton, and a starting (LKO) mass of 100 tons.

The numbers seem mostly believable, too. We can also double check our prediction from the original "posit" assumption is self consistent. At the optimal Numstages ,   (mpayload/mfull) (which is the stage mass ratio) is always the same irrespective of (mpod/mcraft) (The craft mass ratio) ... Success! Just as an aside, this result seems weird given how the craft mass ratio is stuck in a logarithm with a summed term, but it's something we should expect physically and the equation somehow bears it to be true.

This graph also consistent with our previous graph, where the dots I've highlighted on each graph correspond to the same point, and reassuringly  8998 ~ 4.58*1975  (or the deltaV of our craft is the number of stages times the deltaV per stage) (1/100)^(1/.458) = ~.364, the value of evaluation for the previous graph.

 

 


3. Generalize to a form that's irrespective of craft size ... Results seem mostly good.

Spoiler

We'll take our equations for the specific craft and generalize them to work for any craft of any size. When optimally staging, the deltaV of a craft should scale linearly with the e-fold scale of its mass ratio, so we'll make an equation for this. The value can be viewed as a mass-to-deltaV efficiency factor. In another field, we'd probably call it our 'goodness factor'.

(mpayload/mfull) ^ Numstages = (mpod/mcraft)   (Starting with the first equation from part 2. Next line, flipping and taking a log (ln for convenience))
ln(mpod/mcraft) = Numstages *  ln(mpayload/mfull)      (Next, dividing this from the final equation from part 2.
                                                                Also, substituting the stage mass ratio
(mpod/mcraft) back in to the logarithm in the place of (mpod/mcraft) ^ (1/Numstages))

            ΔVcraft                         - g0 * Isp Numstages ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpayload/mfull) )                 (Next line, canceling Numstages)
                                         =                                                                                                                                                                                                                                     

      ln(mpod/mcraft)                                                  Numstages *  ln(mpayload/mfull)

 

            ΔVcraft                         - g0 * Isp ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpayload/mfull) )                      (Finally inversing the pod/craft in the log on the left to orient it correctly with deltaV)
                                         =                                                                                                                                                                                                         

      ln(mpod/mcraft)                                                ln(mpayload/mfull)

 

            ΔVcraft                          g0 * Isp ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpayload/mfull) ) 
                                         =                                                                                                                                                                                                       

      ln(mcraft/mpod)                                                ln(mpayload/mfull)

 

And that's it! The left is the deltaV of your craft relative to its scale (in e-fold), which should be constant and irrespective of the craft's scale, and we see to be the case on the right. The right only has properties that pertain to individual stages, nothing about the craft. Plotting the left in terms of stage relative mass (mpayload/mfull) creates a graph which seems pretty reasonable, and I've checked parts of it to be true to the best of my ability to tell using KER. Its roots are in the right theoretical places, and the maximum moves in physically sensible ways with different TWRs. I'm definitely not convinced by the values near zero, though. They seem much too high to me. Could still be fine.

image.png

Y axis: deltaV in m/s for every e-fold size of your craft -> ΔVcraft / ln(mpod/mcraft)    ....    X axis: relative size of each stage (with its payloads) relative to the one that pushed it (with its payloads) -> (mpayload/mfull).

The root at ~.875 is in the physically obvious place, where it denotes your craft needing to be all engines without fuel to fit in so many stages so close, the vertical asymptote at the origin also makes sense. Finally the maximum occures in a place consitent with the previous graph: .365^4.58 = .0099, which is within expected limits of the craft mass ratio (.001) we declared in part 2 though this equation doesn't rely on knowing specifics about the craft, just the stages. In words, the stage-mass-ratio to the number of stages power equals craft-mass-ratio. Of course you can't have 4.5 stages IRL, but the math doesn't know that :) .

 

 

4. Plot in terms of more convenient (mfull /mpayload) ... where things are probably definitely wrong

Spoiler

Finally, we'll flip (inverse) our dependent variable to make the plot more directly useful when building a rocket from the pod up to the full craft.

define X = (mfull /mpayload) = 1/(mpayload/mfull)  . It's more convenient because you normally start with the reentry craft, and want to know how big each subsequent stage to push it should be. Plugging this in to the final equation of part 3 gives what should be the final result:

            ΔVcraft                         - g0 * Isp ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * 1/(mfull /mpayload) )              (also simplifying the lower log by pulling out the inverse -> - )
                                         =                                                                                                                                                                                                       

      ln(mcraft/mpod)                                                ln(mfull /mpayload)

 

But look at that non-zero limit on the right of the graph for huge stages relative to payloads. It should be divebombing, because you get asymptotic deltaV returns with huge stages while the mass increases ever linearly, but the graph seems to be approaching some constant. :( 

image.png

Y axis: DeltaV for each e-fold scale of the craft in m/s  -> ΔVcraft / ln(mpod/mcraft)    ...  X axis: relative size of each stage (with its payloads) relative to the one it pushes (with its payloads) -> (mfull /mpayload)

With a stage-to-stage mass ratio of 50, we should have an abysmal deltaV efficiency, but the plot claims otherwise. Frustratingly, the maximum is right where we would expect it to be at 2.78 = 1/.36 (.36 being the optimum from before). Given the graphs are all seemingly consistent with eachother, this hints that the actual problem may have shown up a long time ago. Or perhaps not?

 

 

So, I hit this road block on Friday and attacked the problem from every angle I could think of over the weekend, rederiving the first 3 sections from different conceptual starting points. I slept on it, mulled over it and triple checked everything, but there's obviously something amiss because the graph in section 4 is obviously wrong in the limit of stages being very large compared to their payloads. Can you figure out the right answer? Best of luck!  

 

Terms

Spoiler

 

(mpod/mcraft)     Mass ratio of the entire craft.
(mempty/mfull)      Mass ratio of this stage when it's empty vs when it's full-> the standard element for the rocket equation.
(mpayload/mfull)     Mass ratio of just this stage's payload to its full stating mass. In other words, the size of each stage (with its payloads) relative to the one that pushed it (with its payloads)
                             As an aside, this happens to be the same value as the size of each stage (without payload) to the one that pushed it (without payload) when stages scale geometrically as they do here. Not important, just handy.
TWRmin/TWReng    
The ratio of how much TWR your craft needs at the start of this stage, vs the TWR of your liquid engine by itself. It's a proxy for the mass of the engines relative to the stage.
mempty      The mass of this stage when it's empty (no fuel left in the tanks)
mfull        The mass of this stage when it's full.

The rest should be obvious by name or by context, but please let me know if any are confusing and I'll append them here!

 

 

Future works

Spoiler

This can be used to make a lovely graph/plot which will finally simplify the TWR/Isp tradeoff of engines! If I ever get to the bottom of it...

 

Finally, I'm flagging friendly neighborhood mod @Vanamonde in case another board would be more appropriate. I think this is the most fitting place, but let's see where we end up!

Edited by Cunjo Carl
Link to comment
Share on other sites

Maybe I finally got it? It might all be correct after all, and I was just looking for a decay-to-zero that was way farther out there than I expected. I just realized that if we're plotting efficiency relative to a logarithmic mass ratio, the value actually shouldn't decline very quickly. We should only be able to see the decline on an exponential scale, so I replotted in terms of one, and got something I'd really like to believe!
 

Spoiler

 

define x = ln(mfull /mpayload) so that x is the log scale of each stage in our rocket 

   (mfull /mpayload) = e^x     We can rearrange for a more convenient form and plug it in to our equation from part 4.

 

            ΔVcraft                         - g0 * Isp ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * e^-x )   
                                         =                                                                                                                                                                   

      ln(mcraft/mpod)                                                    x

image.png

Y axis: DeltaV for each e-fold scale of the craft in m/s  -> ΔVcraft / ln(mcraft/mpod)    ...  X axis: Relative size of each stage to the one it pushes on an e-fold scale -> ln(mfull /mpayload) or, newly coined, x.

From KER, the asymptotic limit on deltaV in KSP starts showing up at a stage-to-stage mass ratio of 7x (2 e-fold), it becomes very apparent by a stage-to-stage mass ratio of 20x (3 e-fold), and it really hits home at a stage-to-stage mass ratio of 50x (4 e-fold) ... These values seem to match.

 

 

It seems to be working out, but I'd still love a second set of eyes on all this. If the urge to take on some math strikes anyone, some corroboration (or rebuttal) would be hugely appreciated.. Otherwise I'll probably mark it as solved in a few days.

Edited by Cunjo Carl
Link to comment
Share on other sites

I can't find any error on your math.

On the problem of the 4th part: The graph might look a bit off, but the relative dv for stage-to-stage ratio of 50 is only 1200m/s. So it's not that much.

This result is also consistent with the last part.

 

Besides, I found this online plotter which has grid to make things clear. It seems that we like to enlarge small things in our brain.

EDIT: Even NERVs doesn't seem to bother staging on low TWR. (TWR 0.6 is high for nukes, isn't it?)

EDIT2: Also, even though the graph doesn't seem to converge to 0, math says that it should converge to zero. ln(x) is one of the most slowly increasing graph which in turn diverges to infinity.

Edited by Reusables
Link to comment
Share on other sites

Assume we do want to ignore decoupler mass (which is important for many stages, but let's ignore for now to be consistent with all you've done). This nonzero limit is still explainable - you treat the staged engine & fuel tanks as "propellant" as well. This will of course reduce "calculated" Isp - but it still has a nonzero lower bound (this involves some calculation but not too hard, something like newIsp = Isp/9 or something better than that). This will mean that you could apply rocket equation to get a lower bound of the whole craft's delta V budget, which is nonzero.

Link to comment
Share on other sites

 

I'm somewhat confused. Particularly, its not clear to me why, or if, what works so long as we're using the same engine specs everywhere would still be valid when we decide to use different engines for each stage (as we usually do when building a rocket in game). In the same vane, what happens if we decide to drop tanks (but not engines) at some stages or use a asparagus/onion arrangement?

 

Link to comment
Share on other sites

That's what confuse me. I'm not seeing how it relates with the general case.  Will the assumptions made for the particular case remain valid?  Or the math need to be done again from scratch? 

 

Link to comment
Share on other sites

@Abastro

I like the plotter you recommended, the grid makes it all much easier to see!

Now I'm feeling more confident about the results (huge thanks for checking through them!) I was planning to make a tutorial thread with a big friendly diagram for what all the terms refer to. I'm also planning on writing a solver to make some nice boiled down graphs, which I might send back to the discussion section at some point. I've just started using the results from my google graphs, and it's helped pushed a couple of my designs further than I was able to with just my normal educated guess and check, so the final proof is in the pudding.

Thanks for doublechecking the limit mathematically. That ln/ln was giving me trouble (though given there was a 1/x in the top it probably shouldn't have :) )

 

@FancyMouse You're absolutely correct that if we consider the engine and fuel tank mass to be fully burnable, we would expect a non-zero limit. I like your idea of making a relative Isp term for comparing cases, I'll have to give it a shot and see if it leads to any new ground. In the meantime, the mass of fuel tanks and engines seems to be driving the limit down to zero eventually, which is very relieving to me. Thanks for the ideas!

 

@Spricigo It's looking like the specific-craft different-engines case is going to require a solver, though I still have some hope of finding a graphical or heuristic solution. While it's easy to make some simple test cases and plots, I'm having a hard time figuring out what assumptions to make and where to even start!

   The problem is coupled with the case of requiring different TWRs from different stages (same engine), which I was able to solve generally. Unfortunately, the different Isps have been much stickier to deal with. Even so, I've been using the plots and getting good results in my recent craft design, which ranges from ants through skippers. I feel like for engines with equivalent efficiency (the max y value from plot in section 4 : DeltaV/ln(mcraft/mpod) ) the values will lean towards making the engines with the better TWR the somewhat bigger stages... I may totally change my tune on this in 10 minutes though.

   Asparagus stages (and drop tanks) can be handled by treating the TWRmin as the TWR being provided by the engines on just this stage (or 0 for a tank). Though unless you count in decouplers, the drop tank result will tell you to just use infinite stages! :D Math is great.

I totally want to crack the general multi-engine case though! It's one tough nut.

I'm going to mark the problem as solved and keep trucking through the next steps. If anyone gets a yen to do some math and join along, just let me know and I'll put you in the loop.

Thanks again!

 

Edit: I'm also not exactly sure how this will relate to the general multi-engine case in the end. I have plenty of equations, but I'm yet to get a good feel for it. Solver's my fallback plan, but I'm still hoping a good heuristic solution will emerge from the depths.

Edited by Cunjo Carl
Link to comment
Share on other sites

I've been thinking about this, and I had an idea. If you could get general equations using the same set of variables for vessel mass and vessel delta-V, given a certain number of stages, you could relatively easily use some calculus to find an analytical solution for the optimal staging setup given a certain constraining mass. The question then becomes working out a general-form equation for the delta-V of the full setup. If we're accounting for multiple engines, the Isp and TWR change from stage to stage, making it difficult to get a general equation, for an arbitrary number of stages, for an arbitrary number of engines per stage.

Which leads me to my next thought. The best way to approach this would probably be to work out equations for a fixed number of stages (so a 1 stage equation, a 2 stage equation, etc.). Then, find the optimal engine/fuel tank ratio for each one of those. Whichever number of stages provides the most delta-V is the optimal one. The problem then becomes tying Isp to TWR in a reasonable way. We already know the mass ratio for the fuel tanks, but engines are a bit trickier. Optimally, there would be a consistent relationship between the two, but there really isn't. I plotted the relationship, with TWR on the x axis and Isp on the y axis here. I'm not considering the Twin Boar for now, for purposes of simplicity.

As I see it, there's only one analytical solution to this: Giving the quantity of each engine its own variable. This would provide an analytical solution, but in the form of a system of seventeen (ish) equations. We can probably ignore the Thud, Ant, and Spider, but I hesitate to throw any other motors out the window, and I'm only ignoring those since their optimal use case is not as a transfer stage motor.

Asparagus and drop tanks, you say? They'd probably require their own sets of equations. The more I think about this, the more I start to think that a solver is the way to go.

Or, in other words, I've got an urge to do some math and am interested in helping with the general-case solution.

Link to comment
Share on other sites

@IncongruousGoat Sweet!

I've nailed down the base formula for the general multi-engine case, but finding a way to extract optima from it is a whole 'nother story, and I'd be very happy to have your help. I actually did exactly as you had suggested by starting with the specific-craft multi-engine case (fixed size and stage count) and then generalizing to undetermined size. The result was pretty unsurprising! I'll make a better writeup of it to get us on the same page tomorrow, but for now the result worked out to:

for a general craft with many stages using engines p or q, we need to specify what portion of stages will use each engine(other wise the math goes slippy-fish and just uses all of one engine or another). If we choose a 50/50 mix, we get:

deltaV/ln(craftMassRatio) = -g0 * (1/(p+q)) * (  Ispp*ln(1/9 + 8/9 * (TWRmin/TWRenginep) + 8/9 e^p) + Ispq*ln(1/9 + 8/9 * (TWRmin/TWRengineq) + 8/9 e^q) )       <<<p and q are the e-fold scale of each stage... aka. ln(stageMassRatio), I also use them for subscripts... sorry. Will fix! >>>

It's basically exactly the equation from my reply with the two engines grafted together in (to my surprise) the obvious way. I'll need to doublecheck my math and starting principals, but call me 90% sure! It should also extend to further engines following the same pattern. There is an analytical solution to the two engine case.... I wish I still had it, I tossed a version of this equation into wolfram alpha and it spat back a 20 term jungle of gibberish. I made a this face :/.

Hey, I like the engine plot! That's a good way to look at them. I'm not quite following the engine/fueltank ratio, but the optimal engine to tank ratio can be determined by the end-user in the form of a minimum TWR requirement for that stage... I've been calling it TWRmin for lack of a more creative term. Given this (and the engine's TWR) we have the mass of the engine required for the stage, and with it a link to Isp through the rocket equation. MassEngine = MassStage(w/payload)*TWRmin/TWRengine

I'm really not sure what next steps are. What end result are you looking to make from this?   For me the ideal solution would be a set of plots showing the ideal stageMassRatio for each engine by itself across the TWRs. Then a set of plots showing how far from this deltaV optimum you fall for having a higher/lower stageMassRatio given a handful of different (TWRmin/TWReng), and finally a set of plots showing how these need to be altered to handle multi-engine chicanery. Or, maybe a little webapp would show it all more easily? Hm...

Ignoring the Thud is something I'm good at :).

For now do you have any questions or comments from the stuff I've got up in the topic? It's not the best organized yet, but it should be a good starting point.

Link to comment
Share on other sites

I've played around with the math with the simple multi-engine case, ignoring those decouplers. I think I got something here.

 

1. Optimum on Fixed number of stage & Fixed engine properties for each stage

Spoiler

Let's fix the number of stageengine properties for each stage and the payload-full mass ratio.

 

We have this here, for individual stages:

EXQmuu2.png

Let's rewrite this with per-engine constants. Regard the payload as the last stage, and let m_k be the full mass of k-th stage.

Then the dv of the of the k-th stage is:

w4kkhZH.png

Simple enough! (Spot that p_k is related with the Isp and t_k is with the TWR)

 

Now let's define some terms here.

gNpH8e5.png

So x_k represents (the logarithmic scale of) k-th mass ratio, and X does the payload-full mass ratio.

We need to maximize the total delta-v on fixed X and positive x_k's (these are the conditions).

TvxtL4X.png

Here, we can see that the total delta-v is actually function of x_k's.

So this optimization problem is determining the maximum of the function with given conditions.

 

Spot that the dv is also continuous function. Actually this is huge benefit for us,

 because it means,

 that the maximum exists, and is on either on the boundary (which is given by the conditions) or one of the local maximums!

Moreover, 'on boundary' means x_k=0 for some k, which implies actually it's composed of less than k-1 stages!

As we'll cover number of stages later, it's enough to seek for the local maximum, which is global maximum as well.

 

To find where actually the local maximum lie on, let's consider the two-stage case first.

It's quite simple case, as x_1 and x_2 will be x and X-x for some x, and dv is simply function of x.

Like this:

oA7jCGa.png

See?

 

Now on local maximum, the derivative of this function is 0.

uCRDFpS.png

This implies something important:

The ratio between p_i and 9/8*tex+1 is constant on the maximum!

 

Moreover, this is the same for the maximum on any number of stages. (- local maximum case)

Spoiler

  Suppose it isn't. Then we can simply choose the two (i,j) with the different ratio, which will lead to contradiction.

  As it's neither a local maximum nor boundary maximum on two-stage (i,j) cases,
   we can adjust x_i and x_j to get higher dv while keeping x_i+x_j as constant.

  Then, while it still satisfies the condition, the total dv is higher than so-called maximum as well!

(Or simply, multi-stage case should be optimal for each two stages - when the mass ratio is constant)

 

So we got this:

uBCe5wB.png

Where C is constant, which is only dependent on X and engine properties. (As we'll see later)

We can easily see that this fixes each x_k:

Q7JBSUj.png

and then

LAtV9RT.png

From these, we can derive the dv on this maximum, and the relation between C and X.

s4fFUIR.png

kIzq8Bw.png

Any maximum derived from local maximums should satisfy this.

And as we above, every maximum is local maximum on certain number of stage.

 

Besides, it could be important to note that there exists only one C for each case.
  (i.e. there is an unique C with the condition above)

It's because X is increasing function in perspective of C, ranging from negative infinity to positive infinity.

IKsMoHG.png

So it's bijective function, which means there exists C uniquely.

 

I'll deal with variable number of stage later.

Edited by Reusables
Added the pic.
Link to comment
Share on other sites

@Cunjo Carl Going back and reading what I wrote, I realize that my point about TWR was a bit... confusing. I was trying to point out that wet mass/dry mass ratio is consistent across the liquid fuel tanks (well, all the ones we care about), but that there is no consistent relationship between TWR and Isp in engines, and that the lack of such a ratio makes the math more difficult.

I'm actually more looking for a solver program, although probably not a webapp, since I have absolutely no experience with web programming.

Anyways, math. Based on @Abastro's work I started trying to work out the general case for n stages, given that we know what motors we're using for each stage (and only one type of motor per stage), and it would seem like there isn't an analytical solution. There's a numerical solution, one I could write a program to deal with, but not analytical solution.

Spoiler

Starting with the general equation for delta-v:

1hMk47J.png, where Y77ai6f.png

The constraining function g(x) can then be written

hgavk59.png.

Computing gradient vectors for both, we get:

wpvXt0a.png

and

JGWPasO.png.

Using the method of Lagrange multipliers, it follows that, for every xi:

ChIMq8h.png, where lambda is some constant. Which means that every component of the delta-V gradient vector is equal to every other, just as it was in Abastro's calculations.

Given that all the components are equal, we can (with some algebra) say that

Fsc1YsL.png.

Great. Now we can write every single xi in terms of x1. So, we just write out all the formulae for all of our x's and plug them into the constraining function. It's here that we have a problem. The resulting equation, in all cases with n > 1 stages, isn't solvable algebraically. This is because there are a whole bunch of x1s inside exponential functions, and one that isn't. Now, dealing with this numerically isn't too complicated. But there isn't a neat analytical solution to this problem.

 

Oh, wait. Decouplers are a thing. Hm. Honestly, I don't think the mass of a decoupler is going to make too much of a difference in these calculations one way or the other.

Edited by IncongruousGoat
Terminology
Link to comment
Share on other sites

1 hour ago, IncongruousGoat said:

The resulting equation, in all cases with n > 1 stages, is transcendental.

...

But there isn't a neat analytical solution to this problem.

Really? I'm sure that I can rewrite the equation above into polynomial equation. So analytic solution does exist for number of stage less than 5, isn't it?

Besides, great work! Now it's much more clear.

Link to comment
Share on other sites

5 minutes ago, Abastro said:

Really? I'm sure that I can rewrite the equation above into polynomial equation. So analytic solution does exist for number of stage less than 5, isn't it?

Besides, great work! Now it's much more clear.

Ah. Whoops. Messed up my terminology. I meant to say that it can't be solved for x1 algebraically.

EDIT: There, I fixed it.

Edited by IncongruousGoat
Link to comment
Share on other sites

I made a spreadsheet solver for the general-ship multi-engine case... and it works! Before I forget things (a problem with me) I'm going to post the link/description, the math, and then I'm really looking forward to reading your post on the analytic solution for the specific-rocket multi-engine case, @Abastro and the your constraints for the general-ship multi-engine case, @IncongruousGoat.

Link to the spreadsheet solver

The idea is to insert your engines and stage requirements, and then insert "1" as a starting guess for stage scale on each stage type. IN a big matrix below, it then shows what the deltaV efficiency would be for a given change to each stage scale, and you just start picking all the best changes, and plugging them back in. A couple iterations, and you're set! Stage scale is ln(masspayload/massfullstage). So far, it's matching values I'd expect from fussing with rockets, but I haven't run it quantitatively by KER yet.

ok. Gonna start editing the post.

The original link wasn't an editable link. Just updated, so try clicking again if it didn't give access.

 

Oh my gosh, the forums just ate my 3 hour long edit to this post. aggghhh. ;.;

Edited by Cunjo Carl
Link to comment
Share on other sites

Let's try this again. It'll be a lot less polished sadly, because I need to go to bed very soon.


 

Spoiler

 

So we want to get the best deltaV for our craft, but the question is, the best deltaV relative to what? The obvious answer is the craft's mass ratio, but this winds up being different for different sizes of craft because deltaV scales logarythmically. So we instead take advantage of this, and declare our deltaV efficiency to be ΔVrocket / ln(1/craft mass ratio). This stays the same regardless of how big your craft is or how many stages it has.

Terms

i                                                         a subscript for a certain type of stage (rocket type, TWRmin). Sums and products are always across this.
F   -- was (mpod/mcraft)
                     Mass ratio of the entire craft. Mass of the final pod relative to the mass of the original craft. We won't ever actually know this value.
fi   --  was (mpayload/mfull)                  Mass ratio of just this stage's payload to its full stating mass. In other words, the size of each stage (with its payloads) relative to the one that pushed it (with its payloads)
xi = ln(fi)    ,    fi = e xi                          The size of the same stage on a log base e scale. This is extra convenient because most optimal stage sizes are ~2.7 .
Ni                                            The number of a certain type of stage (rocket type, TWRmin)
N, ni                                        A scaling factor for all stages , and the portion of stages which are a certain type (any scale is ok as long as it's consistent. "2:1")
ai  =  1/9 + 8/9*TWRmin,i/TWReng,i          A convenience variable        
b =   8/9                                             Another convenience variable

 

Equations

ΔVstage = -g0 * Isp,i* ln(1/9 + 8/9*TWRmin/TWReng + 8/9 * (mpayload/mfull) )               This is the deltaV for a single stage, as derrived in the first part of the topic post.
ΔVstage = -g0 * Isp,i* ln(ai + b * fi)                                                                             This is the same equation rewritten with the current terms. Much cleaner!

Ni = N * ni                                                                                                           The number of each type of stage can also be written as their relative portion times a scaling factor. That factor will cancel out.
ΔVrocket = SUM( N * ni * -g0 * Isp, * ln(ai + b * fi) )                                                        The rocket equation can be summed across all stages to get the deltaV of the full rocket.
ΔVrocket = -N * SUM( ni g0 * Ispi,i* ln(ai + b * fi) )                                                         rearrange to get ("EQ.1")

F = PROD ( fN * ni )                                                                                The total mass ratio of the rocket is the product of the mass ratio of every stage, or alternatively the product of each kind of stage to the power of how many of that type there are.

ln(1/F) = - N SUM (ni * ln(fi))                                                                 The same as above, rewritten for our convenience. ("EQ. 2")

 

    ΔVrocket           SUM(  ni g0 * Isp,i* ln(ai + b * fi)
-----------------  =  ------------------------------------                                                Dividing the deltaV of our rocket (EQ.1) by the equation above (EQ.2) gives us our general equation.

      ln(1/F)                     SUM (ni * ln(fi))

 

And finally, swapping the mass ratios f with their natural logs (e xi) to make the analysis a lot easier to view.
 

    ΔVrocket           SUM(  ni g0 * Isp,i* ln(ai + b * e xi)
-----------------  =  ---------------------------------------- 

      ln(1/F)                      SUM (ni * xi)

 

 

Yaay. The nice part about this is it doesn't have any mixed terms! It's not completely separable, but since the effect of each type of stage (each i) appears only in sums, you can make a crazy easy solver which just adjusts 1 variable at a time and works its way to the global optimum (there's no local optima or cross dependencies). We don't need to handle it as 17 simultaneous variables, we can do them one at a go with a bit of itteration. Not nice for analysis, but very nice for computation. We just need to choose a starting x for each, and 1 happens to be a good choice.

Spoiler

The effect of altering a variable (xi) can be handled as: ΔVefficiency = ( ΔVrocket,0 - ΔVstage,0 + ni g0 * Isp,i* ln(ai + b * e x0 + Δx) ) / ( SUM (ni * xi,0) + Δx )

The 0 subscript mean "original"
If you're altering the mass ratio of a stage by Δx and want to see the new deltaV efficiency: Start with the deltaV of the rocket (without the N terms for this case), subtract the old deltaV of that stage and add the new one (evaluated at x0 + Δx ). Then divide by the sum of the scales of the stages and additionally your Δx. Given this, we can find the optimum of each as part of separate equations, with values that are easy to track and update. I'll work the math in later.

Ok. It was the big sigma and pi that crashed it. Weird, it handles big delta ok...

I'm really looking forward to reading your posts! I kinda feel like a spreadsheet solver is a copout, but at the same time I'm also looking forward to optimizing a lander I've been tinkering with :D . I'm looking forward to seeing the deeper analytical solutions afoot tomorrow.

 

Edited by Cunjo Carl
Link to comment
Share on other sites

8 hours ago, Abastro said:

I think I can easily derive the optimal case if continuous number of stage was a thing. (In the case putting the best engine is optimal)

But as stage number is quite restricted, I can't just say that way.

A continuous number of stages isn't actually such a bad thing- it's pretty much the only difference between the specific-rocket and general-rocket case. The general rocket (where we don't declare a size or anything) doesn't care whether you have .25 of each stage or 1000, so long as the relative number of each stage to the others is known (or a variable). In this way, I think allowing yourself to go ham and declare the number of stages to be continuous is not a bad thing, it should apply nicely to the general case! Unfortunately, like you said, if you don't choose something to constrain the relative number of each stage, the math will just tell you to use your best engine and none of the others. My constraints are stage number ratios that need to be hardbaked into the optimization calculations, but maybe there's a cleaner way?

 

Link to comment
Share on other sites

On 5/18/2017 at 3:08 AM, Abastro said:

 that the maximum exists, and is on either on the boundary (which is given by the conditions) or one of the local maximums!

Oh... I was wondering how to prove that! My "it's just a buncha things plussed together, shouldn't have local non-global maxima!" seemed a bit hand wavey.

For your equation that found the expression that equaled out to constant C for all stages, I'm impressed you found the thing that balances the stages! I'm also happy it didn't have a log :) . My similar analyses of the n stage equations all hit dead ends at this point with pretty but unsolvable relations, so I'm glad this one worked out. I was starting to give up hope of finding a starting point to launch a heuristic approach, but this would be key.

 

On 5/18/2017 at 4:16 PM, IncongruousGoat said:

Using the method of Lagrange multipliers, it follows that, for every xi:

I followed right up to here! :lol: I wish I could say more, but I'm impressed with the result. How did you make the constraining equation g = <1,1,1,...>?

 

I tried the old engineers tricks of linearization, and forming systems of seperable PDEs, but it all gets sticky or pretty-but-unsolvable.  It's frustrating, because I feel like I keep getting so tantalizingly close. I hope one of your deeper analyses into the specific rocket systems pan out! Anyways, I've hit my head against the analysis enough, I'm thinking I'll try making the google sheet nice enough to post for others to use... Maybe with asparagus stages supported; I have a feeling that the folk who would like a deltaV optimizer are the same as the folk who like them some asparagus! It's all just book-keeping math from here, but would either of you like to join? If so, I'll send the link for the new version.

 

Edited by Cunjo Carl
Link to comment
Share on other sites

Just now, Cunjo Carl said:

I followed right up to here! :lol: I wish I could say more, but I'm impressed with the result. How did you make the constraining equation g = <1,1,1,...>?

Since the constraining equation is just the sum of all the variables, the gradient vector works out to <1,1,...,1>, since for each partial derivative one variable gets reduced to 1 via power rule, and the rest go to zero since they're being treated as constants.

In other news, I've started work on a solver program using the equations I came up with. So far the math looks promising-I'm planning on using Newton's method to approximate a solution. Interestingly, the number of stages doesn't change the computational complexity of finding the optimum mass arrangement, given a certain set of motors. Of course, more stages changes the overall complexity, just because you have to check more possible motor arrangements, but that was to be expected. The real roadblock so far has been setting up the build environment-my computer isn't set up to build cross-platform C++ programs with UIs, so I've been spending the afternoon dealing with that. I'll release it on GitHub (and provide a link, of course) once it's working.

Link to comment
Share on other sites

2 hours ago, Cunjo Carl said:

Oh... I was wondering how to prove that! My "it's just a buncha things plussed together, shouldn't have local non-global maxima!" seemed a bit hand wavey.

It's one of the fundamental theorem in real analysis.

https://en.m.wikipedia.org/wiki/Extreme_value_theorem

The generalized version.

This is actually quite hard to prove... :P

Link to comment
Share on other sites

1 hour ago, Abastro said:

It's one of the fundamental theorem in real analysis.

https://en.m.wikipedia.org/wiki/Extreme_value_theorem

The generalized version.

This is actually quite hard to prove... :P

For your theorem it is easy if you know topology - continuous function maps compact set to compact set. And compact set on real line is bounded and closed, so max and min exists.

OTOH this has nothing to do with the original question - "shouldn't have local non-global maxima" is literally equivalent to "global maxima that is not on a boundary, is a local maximum", and it's trivial just based on the property that it's a "global" maximum.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...