Musk explains why SpaceX prefers clusters of small engines • Hacker News Board

Re: Musk explains why SpaceX prefers clusters of small engines

#61

Post by Florin_Andrei » Thu, Feb 08, 2018, 8:11 PM UTC

shmerl wrote: post #32

orbital-decay wrote: post #15

Earlier quoted context omitted.

Actually, N1 failures had little to do with the complexity itself, and engines were reliable enough for the time. Due to the lack of funding (the soviet lunar program was given the priority well into the moon "race") they were using the old methodology of testing it in the actual flight, not doing any static fires and only doing a bare minimum of ground testing. Saturn V, on the other hand, heavily relied on the grou…

> engines were reliable enough for the time. Engines alone could be, but the their combination wasn't reliable because of interactions between them and need for synchronization. As Musk points out, it was an avionics problem.

The main reason why they failed is - they pushed testing into production, just like MySpace, because their funding and leadership disintegrated at the beginning of the program. See my other reply in this thread.

Re: Musk explains why SpaceX prefers clusters of small engines

#62

Post by ethbro » Thu, Feb 08, 2018, 8:12 PM UTC

neltnerb wrote: post #48

bunderbunder wrote: post #36

Earlier quoted context omitted.

How does one quantify the risk of cascading failure? My initial instinct, informed by computing, is to say that it's easier to avoid cascading failures in the system that is composed of more, smaller parts. All other things being equal, in a rocket with 5 engines, if one of them fails, then each of the remaining ones needs to pick up 1/4 of the slack to compensate. In a rocket with 9 engines, not only would each of t…

To answer the first question, you use a fault tree analysis to predict potential failure starting points (like a broken component) and then describe how those failures will propagate through the system. https://en.wikipedia.org/wiki/Fault_tree_analysis For an example, say I'm building a system that needs to hold a block of aluminum at 550C, 99% of the time. Okay, so you add a thermocouple and a heater to it, easy. Wh…

Is there a name for (or keywords to search for) weighing the tradeoffs between attempting to reduce failure effects in a component itself vs addressing them at the system level?

E.g. while you could mechanically debounce a button itself, it's usually easier to engineer the system in such a way that trigger bounce doesn't cause issues

Wondering how the call is made on where the appropriate fix to increase reliability should be made? Or is all bespoke / gut?

Re: Musk explains why SpaceX prefers clusters of small engines

#63

Post by Robotbeat » Thu, Feb 08, 2018, 8:15 PM UTC

theothermkn wrote: post #60

Robotbeat wrote: post #54

Earlier quoted context omitted.

It's true that pressure vessels in principle don't care about scale when it concerns mass per unit volume (at a constant pressure). But a combustion chamber's thrust is (to zeroth order) proportional to cross sectional area, not volume. The combustion chamber only needs to be a certain length (L star) to achieve efficient combustion. Any longer and you're just adding mass with no benefit. But there are practical limi…

> You can't have it too squat or it loses structural efficiency. I'm not sure what you mean. Over "squatness," if we mean l-star to cross-sectional area, the 'structural efficiency' remains constant, in that we've contained (square) more fluid for (thickness x perimeter = square) more wall material, and done so for (square) more thrust. > You can use a much shorter, and thus lighter, nozzle if you have a smaller engi…

Pressure vessel equation means structural efficiency is invariant based on volume but we're talking (to zeroth order) area, thus smaller pressure vessels (nozzles, chambers, etc) are more structurally efficient (at the large size limit...).

To expound: Mass ∝ Volume, Volume ∝ length^3.

Thrust ∝ cross sectional area, area ∝ length^2.

Thus, Mass ∝ Thrust^(3/2), or:

Thrust to weight ratio ∝ sqrt(thrust) for a single engine.

> The point being that, if your nozzles are 9 times smaller, they're only 9 times lighter.

This is incorrect, for the reason I shared earlier. Thrust is proportional to cross section, not volume. Thus scaling laws (at some point) favor smaller engines. (Note that this is assuming we're already big enough that we have full combustion and are not experiencing minimum gauge issues, etc.)

My knowledge doesn't come from being a SpaceX enthusiast. In addition to having a physics degree, years ago I was part of a very early-stage startup (never got off the ground) at one point looking at launch vehicles, and so I read Sutton's Rocket Propulsion Elements (a very nice introductory text, I highly recommend) among others and did a bunch of scaling analysis. (SpaceX would've been a competitor.)

Re: Musk explains why SpaceX prefers clusters of small engines

#64

Post by Gravityloss » Thu, Feb 08, 2018, 8:24 PM UTC

avmich wrote: post #24

mhandley wrote: post #12

There are two other reasons which SpaceX has mentioned before: - When you're landing a rocket, you need to be able to throttle down quite low. Even a single Merlin 1-D engine, throttled down, is too much thrust to be able to hover with a nearly empty booster. It's really hard to get stable combustion at very low throttle settings. Having only one engine out of nine running for landing makes this much more manageable.…

> When you're landing a rocket, you need to be able to throttle down quite low. When R-7 was developed in 1950-s, as a weapon, one of requirements was the precision of attained speed at the moment of engine cut-off. It was solved by shutting down main chambers on the upper (second) stage, powered by RD-108 - 4 chambers about 20 tons of thrust each - and maintaining thrust from steering chamber, 4 of them, 3 tons of t…

That'd be quite something, improving the Soyuz to do powered landings. Talk about getting mileage from your design.

On the other hand, it can't even stand on the pad fully fueled, it's hanging from an arm...

Re: Musk explains why SpaceX prefers clusters of small engines

#65

Post by DanCarvajal » Thu, Feb 08, 2018, 8:36 PM UTC

Hey it worked for the N1.....wait.....

Re: Musk explains why SpaceX prefers clusters of small engines

#66

Post by cuspycode » Thu, Feb 08, 2018, 8:46 PM UTC

Florin_Andrei wrote: post #58

orbital-decay wrote: post #15

Earlier quoted context omitted.

Actually, N1 failures had little to do with the complexity itself, and engines were reliable enough for the time. Due to the lack of funding (the soviet lunar program was given the priority well into the moon "race") they were using the old methodology of testing it in the actual flight, not doing any static fires and only doing a bare minimum of ground testing. Saturn V, on the other hand, heavily relied on the grou…

The Soviets won the first round of the space race (until the mid-60s) because of multiple factors, but mainly because of the laser-focus at the highest levels to push the technology as far as it could go. It helped a lot that they had an engineering genius heading the program (Sergey Korolev), and the top politician during that time (Nikita Khrushchev) was a forward-thinking progressive (relatively speaking - please…

Korolev's contribution is even more impressive when you consider that he was imprisoned in the Soviet Gulag for many years (for political reasons), suffering under living conditions which probably shortened his life.

https://en.wikipedia.org/wiki/Sergei_Korolev

Re: Musk explains why SpaceX prefers clusters of small engines

#67

Post by perlgeek » Thu, Feb 08, 2018, 9:02 PM UTC

ksk wrote: post #8

>For computers, Musk said, using large numbers of small computers ends up being a more efficient, smarter, and faster approach than using a few larger, more powerful computers. I always figured, in theory, a super-super-powerful single threaded single processor would out compete the multi-threaded multi processor design on efficiency, because of the hardware and software inefficiencies in inter processor hardware con…

> I suppose there is always a physical limit on the total capacity of low latency addressable ram and storage you can manage to shove into an architecture.

Some people even argue that, due to these physical limits, storage access time tends to scale O(sqrt(N)) with the size N of the storage, including for RAM.

http://www.ilikebigbits.com/blog/2014/4/21/the-myth-of-ram-p...

Re: Musk explains why SpaceX prefers clusters of small engines

#68

Post by shmerl » Thu, Feb 08, 2018, 9:06 PM UTC

Florin_Andrei wrote: post #61

shmerl wrote: post #32

Earlier quoted context omitted.

> engines were reliable enough for the time. Engines alone could be, but the their combination wasn't reliable because of interactions between them and need for synchronization. As Musk points out, it was an avionics problem.

The main reason why they failed is - they pushed testing into production, just like MySpace, because their funding and leadership disintegrated at the beginning of the program. See my other reply in this thread.

Sure, their management was erratic. But the bottom line, their combination wasn't technically reliable (why, is already what you are saying).

Re: Musk explains why SpaceX prefers clusters of small engines

#69

Post by allthenews » Thu, Feb 08, 2018, 9:14 PM UTC

There's something I don't understand about space travel.

We made it to the moon in 1969, on the first computer to use ICs[1]. Since then we've seen monumental advances in computer science, material science, manufacturing, rocketry, and just about any other component of space flight.

Why 50 years later is it still such a relatively difficult task to launch a rocket into space? Why is it still so expensive and failure prone, when we were able to launch so many vessels with substantially less capable technology? It seems like space travel simply has not scaled with the rest of our technology, but I imagine I'm missing something.

Perhaps the ratio of human life to risk tolerance has increased, such that we effectively spend more time and resources designing away failures and refuse to launch with the same level of risk that was acceptable decades ago?

1. https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Desig...

Re: Musk explains why SpaceX prefers clusters of small engines

#70

Post by lorenzhs » Thu, Feb 08, 2018, 9:14 PM UTC

Florin_Andrei wrote: post #58

orbital-decay wrote: post #15

Earlier quoted context omitted.

Actually, N1 failures had little to do with the complexity itself, and engines were reliable enough for the time. Due to the lack of funding (the soviet lunar program was given the priority well into the moon "race") they were using the old methodology of testing it in the actual flight, not doing any static fires and only doing a bare minimum of ground testing. Saturn V, on the other hand, heavily relied on the grou…

The Soviets won the first round of the space race (until the mid-60s) because of multiple factors, but mainly because of the laser-focus at the highest levels to push the technology as far as it could go. It helped a lot that they had an engineering genius heading the program (Sergey Korolev), and the top politician during that time (Nikita Khrushchev) was a forward-thinking progressive (relatively speaking - please…

Korolev also spent almost six years in a gulag in the 30s/40s after being denounced in what likely was likely some dude's play to replace him. He had a bitter rivalry and lots of differences in opinion with his engine designer/supplier, Valentin Glushko (who was arrested for the same made-up offense, but got to continue working on aircraft projects), whom he also held responsible for him nearly dying in the gulag. He ended up actually dying in the middle of N1 development as a late consequence of the catastrophic conditions during his imprisonment.

It really sounds absurd when put like that. And it makes me wonder what the Soviet space programme could have looked like if Korolev hadn't been imprisoned in Stalin's Great Purge.