Recursive Algorithm for Moravec’s Mass Ratio

Computing the mass ratio for a tapered tether (tether mass/tip mass) was first done (to the best of my knowledge) by Hans Moravec in an appendix to his unpublished 1978 paper, “Non-Synchronous Orbital Skyhooks for the Moon and Mars with Conventional Materials.”

(1)    \begin{equation*} \frac{m_{tether}}{m_{tip}} = \sqrt{\pi}(\chi)\exp(\chi)^2\operatorname{erf}(\chi) \end{equation*}

The expression uses the Gaussian error function, erf(x), which is not typically available in a spreadsheet or scientific calculator. erf(x) also cannot be calculated in closed-form–typically the expressions used to calculate it are iterative. Since the tapered tether mass ratio is such a useful design tool to have, I derived a recursive algorithm that computes the ratio in a simple loop, given only the velocity ratio (VR) of the tether (tip velocity/characteristic velocity).

(2)    \begin{equation*} v_c = \sqrt{\frac{2 \tau}{f \rho}} \end{equation*}

Tau is the tenacity (tensile strength) of the material, rho is its density, and f is a safety factor (greater than one).

(3)    \begin{equation*} \chi = \frac{v_{tip}}{v_c} \end{equation*}

Here is the recursion:

(4)    \begin{equation*} \frac{m_{tether}}{m_{tip}} = 2 \chi^2 \exp\chi^2 (1 - s_1) \end{equation*}

(5)    \begin{equation*} s_1 = \frac{\chi^2}{1} \left(\frac{1}{3} - s_2\right) \end{equation*}

(6)    \begin{equation*} s_2 = \frac{\chi^2}{2} \left(\frac{1}{5} - s_3\right) \end{equation*}

(7)    \begin{equation*} s_3 = \frac{\chi^2}{3} \left(\frac{1}{7} - s_4\right) \end{equation*}

(8)    \begin{equation*} s_i = \frac{\chi^2}{i} \left(\frac{1}{2 i + 1} - s_{i+1}\right) \end{equation*}

and here is psuedocode for the recursion:

subroutine getRatio(double VR, int k) {
double VR2 = VR*VR;
double sum = 0.0;
for (int i = k; i >= 1; i--) {
sum = (VR2/(double)i)*(1.0/(double)(2*i+1) - sum);
return 2.0*exp(VR2)*VR2*(1.0 - sum);

With about 8 recursions, the results are extremely accurate. The recursion is unstable when the velocity ratio is greater than about 3, but no one should be building tethers with velocity ratios greater than 3! and you can just use Moravec’s expression with erf(x) = 1.0, which is a pretty safe assumption for x > 2.0 or so.

The following two tabs change content below.
MS, nuclear engineering, University of Tennessee, 2014, Flibe Energy, president, 2011-present, Teledyne Brown Engineering, chief nuclear technologist, 2010-2011, NASA Marshall Space Flight Center, aerospace engineer, 2000-2010, MS, aerospace engineering, Georgia Tech, 1999

About Kirk Sorensen

MS, nuclear engineering, University of Tennessee, 2014, Flibe Energy, president, 2011-present, Teledyne Brown Engineering, chief nuclear technologist, 2010-2011, NASA Marshall Space Flight Center, aerospace engineer, 2000-2010, MS, aerospace engineering, Georgia Tech, 1999
This entry was posted in Space Tethers, Space Transportation, Technology. Bookmark the permalink.

9 Responses to Recursive Algorithm for Moravec’s Mass Ratio

  1. Chris (Robotbeat) says:

    Luckily, this isn’t really necessary.
    Google supports the Gaussian error function:

  2. Chris (Robotbeat) says:

    Google supports the Gaussian error function.
    Try googling:

    Also, if you ever run into some math that Google can’t do for you, there’s always Wolfram Alpha:

  3. Chris (Robotbeat) says:

    Even better, put the whole thing into Google:

    You can also use google to calculate the velocity ratio:
    4 km/s / sqrt(2*3.51GPa/(.97 kg/L))

  4. Karl Hallowell says:

    Huh, you’re just calculating a Taylor’s series where

    1-s1 = \sum_{n=0}^{\infty} a_n (VR)^{2n}.

    If I’m right, it has coefficients, a_n = (-1)^n/(n! *(2n+1)) (which happen to be the traditional series coefficients for the error function, so it looks like both of us are right). That should converge for all values of VR, including VR > 3 and even complex values of VR. The problem though is that you need more terms than 8 to get proper values for VR>3. This is assuming that your algorithm is just calculating the Taylor series through the VR^(2k) term.

    The Taylor series is rather well behaved though. The traditional upper bound for the error for n terms (well through the VR^(2n) term) should be VR^(2n+2)/((n+1)! (2n+3). For n=8 and VR=3, I get an upper bound of 56 on something which I think has a maximum value of sqrt(Pi)~1.772…

    Just run it out till the error term is below the desired tolerance, I think. I do like your form better since it is a lot more efficient with the multiplications than the traditional series form.

    If “tol” is the maximum error that you want, I think

    VR < tol^(1/2n),

    should do and be fairly quick to calculate.

    I wonder if you can come up with a faster way, given that there's a really fast way to compute exp(x) as
    exp(x) ~ (1 + x/(2^n))^(2^n).

    You first compute (1+x/(2^n)) (which can be done by first squaring 1/2 recursively, n times) and then square the term recursively, n times. The problem though is that the original factor has a huge amount of round off error for large n (there is an optimal value of n, past which things get very wrong quickly), but it is probably the fastest way to compute an approximate value of exp(x). Given that erf(x) is just an integral of exp(-x^2), then there might be a really fast (and of course, sloppy) way to calculate erf(x) as well.

  5. Karl Hallowell says:

    I can’t tell, Kirk, but I attempted to post a comment on the approximation you used. I was using a bunch of Latex notation, so I suspect the post might have generated an error. But if it doesn’t appear and you’d be interested in my analysis, I can email it to you. You should be able to see my email address, if I understand correctly.

  6. Karl Hallowell says:

    Heh, what do I care about spam? It’s khallow at martiansunset dot com. I have an error analysis which indicates that your method should converge for all values of VR and some not-so-good ways to estimate how many terms you really need. Finally, if you really need to wring out CPU cycles (which you probably don’t), there’s a really fast calculation for exp(x) which might somehow extend to a computation for erf(x), though I don’t know how.

  7. Dave Täht says:

    Ages ago (and sorry, I lost the spreadsheet), I had calculated out the possible sizes of a launch tower attached to one of the top 10 (at the time) fast rotator asteroids. The minimum distances required for escape velocity were quite nice – in the range of 20km to 200km. At the time, tethers of 60km were feasible and buildable.

    Since you are figuring out taper ratios I’d love it if someone could independently recreate that work with more modern data, and figure out the mass requirements for a tether rather than tower.

    For smaller asteroids (example: , a tether could be used to despin it…
    For larger asteroids (many examples, starting with , a launch tether could be used for launching material into a (hopefully suitable) return to earth orbit.

    I made a few simplifying assumptions when figuring out tower heights – notably assuming that the object in question was spherical, but it was a start at what I hoped would be a Big Idea (the discussion was centered around a “momentum bank” that sputtered out)

  8. Chris (Robotbeat) says:

    It should be noted that at least the Open-Office spreadsheet program (and probably Excel, too) supports erf(x). Google’s online spreadsheet supports erfc(x), which is simply: erf(x)+1=erfc(x), so erf(x)= 1-erfc(x). That’s pretty easy to use for calculations and is what I’ve done so far. Actually, if we can double the specific weight of our current state-of-the-art materials, then a 7km/s tether is feasible (mass ratio of about 100 for a specific weight of about 7GPa/(kg/liter) ).

    So, yeah, most spreadsheets can do erf(x) with just a little prompting.

  9. Dave, tower tethers on the Moon and asteroids is another thing I’m very interested in and plan to write about in upcoming posts. I wanted to get a lot of theory out of the way so we could plunge into some decent analysis on the concepts.

Leave a Reply

Your email address will not be published.