> So why not simulate leaky plumbing? Computer modeling has come a very long way over time.
You're not even close! There is no value in nebulous hand-waving statements about 'a long way'- what does that even mean? Did you not read the rest of my message which had very specific examples of how simulation isn't there yet?
And as for simulating combustion (when fuel leaks onto a hot pipe, say), academia are only just scratching the surface of simulating things like combustion instability in very toy problems, where they deliberately induce some perturbation x on a flow y and sample they system at some frequency that will just about tell them if there's a limit cycle going on. This is still so far away from actually being able to simulate a burning rocket engine properly.
Now of course I must encourage you to stop being so literal. It's not like rocket engineers say 'oh no you can't do simulation with rocket engines, because you can't model leaks properly'. That's preposterous and you're the first person I've ever come across who has inferred it so. What it means is that real actual hardware is very much not like a computer program where you can test something against all inputs and be deterministic about how it will respond because a computer is a comparatively simple, discrete thing. It's a vastly different problem to simulate a rocket engine. This saying speaks to the fact that you can't simulate every paramater of something like a rocket engine - it's just not computationally feasible, and there are plenty of people working on these problems who are familiar with the state of the art of estimation techniques too. It's hard regardless. Oh what I wouldn't give for a real world version of Haskell's QuickCheck!
Here's the thing about simulation. It's not, as you might imagine it is, a little local copy of the universe in your pc where you just arrange all the bits at t0 and say 'ok go!' and come back and see that it's worked so your design is fine. Instead you the engineer make the rules and propagate the system through your rules for a bit. If you haven't thought of a scenario, it's unlikely that your simulation will be able to show it. There are not a whole bunch of hidden states.
Now you can do universe-in-your-pc type simulation which produces very realistic looking results, but to simulate something as complicated as a rocket in flight would probably take longer than the age of the universe per second. And there are still lots of assumptions there.
> You're using a bunch of examples of old failures to imply that new designs will fail in the same way, when the reality is that new designs have the benefit of learning from every single previous failure,
This is the sweetest and most endearingly optimistic thing I've read all day. I imagine you ride into work on a unicorn. There's some validity to what you're saying, of course people say 'ok won't try doing it that way' but like with your simulation comment, I think you just don't know the reality of how these things actually work in practice.
I promise you there are still lots of Fuel Slosh Failures (an interaction of the control law and the fluid dynamics of the fuel tank causing the failure of Falcon 1 2nd flight) out there in the wild that you don't pick up till you actually fly the damn thing, despite I'm sure very thorough simulated control systems in computers on the ground by people who have a deep understanding of control theory. Static test fires never picked up the pogo effect ( http://en.wikipedia.org/wiki/Pogo_oscillation ) which blew up a few rockets and caused engine shutdowns in others. None of these are witchcraft, in that engineers perfectly understand them once they've seen them. My point is that you can't come up with them and swat them in advance in every case because there are just too many possible ways things can perniciously interact to cause you problems.
Likewise, 'every single previous failure' is not that many in rocketry, because there have not been that many rockets. It's not like rocket X blew up because it's failure mode Y was The Failure Mode for rocket X. Rocket X probably took with it to the grave several other possible failure modes, it was just failure mode Y that got there first.
The shuttle flew hundreds of time before that bit of foam broke off and put a hole in the wing's leading edge. We might never know that that particular bit of foam was a Loss of Life waiting to happen if something else had blown up the shuttle sooner. I went to the talk, one of the best talks I've seen in the whole of my career in engineering, by one of the lead investigators of the Columbia disaster. He handed around 2 identical bits of foam, about an inch diameter and 2 inches long. They looked a bit like that dense styrofoam you use in roof insulation. Anyway, these were the insulation foam on the shuttle fuel tank. He then showed us a 200,000fps video of their pneumatic cannon firing these samples at a bit of carbon carbon composite of the sort used in the leading edge of the shuttle wing. The first sample collided and then disintegrated into a cloud of dust, leaving the wing edge unharmed. The second sample collided with the wind edge and punched a huge whole straight through. The whole audience gasped. It turns out the 2nd type of foam was 'trivially' different in some small way, that no one thought would be an issue at design time, but that was the composition of the bit of the foam that broke off and put a hole in the shuttle.
Now, that whole audience was an audience of engineers, and we were all shocked. We all knew that if we were asked to simulate it, we'd say 'well, it's a homogenous foam. this kind of density. this kind of young's modulus. this kind of poisson ratio. this kind of hardness. ok that'll do' and simulated with it. But these 2 kinds of foam were basically identical in all these respects, yet their behaviour was vastly and tragically different. Unless you simulate down to the sort of molecular level, simulations just don't show you this stuff.
So I understand as an outsider [I am making an assumption that you are from your understanding, apologies if you are not] why you might think that 'surely' simulation 'should' be able to be good enough 'nowadays' what with Moore's Law and MCMC and so on. But really honestly no, not to the point you're going to catch the kind of outliers that cause problems.
P.S. I'm not arguing either way on whether or not SpaceX will be safer or not than some marker. I'm sure they'll have among the safest launch vehicles ever flown. But my points so far have been 1) Beware people putting numbers or otherwise strong claims on reliability and 2) I've been trying to kick the tyres of the mental tools and reasoning people from a software background bring to bear when trying to understand things like space hardware. There is a lot more to it.
> P.S. I'm not arguing either way on whether or not SpaceX will be safer or not than some marker. I'm sure they'll have among the safest launch vehicles ever flown. But my points so far have been 1) Beware people putting numbers or otherwise strong claims on reliability and 2) I've been trying to kick the tyres of the mental tools and reasoning people from a software background bring to bear when trying to understand things like space hardware. There is a lot more to it.
Now this I definitely agree with. I may have misunderstood your initial comment, but I was only trying to argue generally against the idea that Elon Musk is somehow out of line for saying that F9/Dragon will be the "safest, most advanced crew vehicle ever flown" because what else do you expect him to say? "We'll make it, uh, as safe as we can, I guess. Safety's a difficult concept, and rocket science is hard, y'know?"
You and I both have experience in space hardware (my guess is that you have more experience than I), so we both know how rediculous it is to put a number on things, but in this thread, we were arguing the same position from different directions. You against the sentiment of "of course it will be safe" and me against "they can't possibly know how safe it will be." Does that make sense?
You're not even close! There is no value in nebulous hand-waving statements about 'a long way'- what does that even mean? Did you not read the rest of my message which had very specific examples of how simulation isn't there yet?
And as for simulating combustion (when fuel leaks onto a hot pipe, say), academia are only just scratching the surface of simulating things like combustion instability in very toy problems, where they deliberately induce some perturbation x on a flow y and sample they system at some frequency that will just about tell them if there's a limit cycle going on. This is still so far away from actually being able to simulate a burning rocket engine properly.
Now of course I must encourage you to stop being so literal. It's not like rocket engineers say 'oh no you can't do simulation with rocket engines, because you can't model leaks properly'. That's preposterous and you're the first person I've ever come across who has inferred it so. What it means is that real actual hardware is very much not like a computer program where you can test something against all inputs and be deterministic about how it will respond because a computer is a comparatively simple, discrete thing. It's a vastly different problem to simulate a rocket engine. This saying speaks to the fact that you can't simulate every paramater of something like a rocket engine - it's just not computationally feasible, and there are plenty of people working on these problems who are familiar with the state of the art of estimation techniques too. It's hard regardless. Oh what I wouldn't give for a real world version of Haskell's QuickCheck!
Here's the thing about simulation. It's not, as you might imagine it is, a little local copy of the universe in your pc where you just arrange all the bits at t0 and say 'ok go!' and come back and see that it's worked so your design is fine. Instead you the engineer make the rules and propagate the system through your rules for a bit. If you haven't thought of a scenario, it's unlikely that your simulation will be able to show it. There are not a whole bunch of hidden states.
Now you can do universe-in-your-pc type simulation which produces very realistic looking results, but to simulate something as complicated as a rocket in flight would probably take longer than the age of the universe per second. And there are still lots of assumptions there.
> You're using a bunch of examples of old failures to imply that new designs will fail in the same way, when the reality is that new designs have the benefit of learning from every single previous failure,
This is the sweetest and most endearingly optimistic thing I've read all day. I imagine you ride into work on a unicorn. There's some validity to what you're saying, of course people say 'ok won't try doing it that way' but like with your simulation comment, I think you just don't know the reality of how these things actually work in practice.
I promise you there are still lots of Fuel Slosh Failures (an interaction of the control law and the fluid dynamics of the fuel tank causing the failure of Falcon 1 2nd flight) out there in the wild that you don't pick up till you actually fly the damn thing, despite I'm sure very thorough simulated control systems in computers on the ground by people who have a deep understanding of control theory. Static test fires never picked up the pogo effect ( http://en.wikipedia.org/wiki/Pogo_oscillation ) which blew up a few rockets and caused engine shutdowns in others. None of these are witchcraft, in that engineers perfectly understand them once they've seen them. My point is that you can't come up with them and swat them in advance in every case because there are just too many possible ways things can perniciously interact to cause you problems.
Likewise, 'every single previous failure' is not that many in rocketry, because there have not been that many rockets. It's not like rocket X blew up because it's failure mode Y was The Failure Mode for rocket X. Rocket X probably took with it to the grave several other possible failure modes, it was just failure mode Y that got there first.
The shuttle flew hundreds of time before that bit of foam broke off and put a hole in the wing's leading edge. We might never know that that particular bit of foam was a Loss of Life waiting to happen if something else had blown up the shuttle sooner. I went to the talk, one of the best talks I've seen in the whole of my career in engineering, by one of the lead investigators of the Columbia disaster. He handed around 2 identical bits of foam, about an inch diameter and 2 inches long. They looked a bit like that dense styrofoam you use in roof insulation. Anyway, these were the insulation foam on the shuttle fuel tank. He then showed us a 200,000fps video of their pneumatic cannon firing these samples at a bit of carbon carbon composite of the sort used in the leading edge of the shuttle wing. The first sample collided and then disintegrated into a cloud of dust, leaving the wing edge unharmed. The second sample collided with the wind edge and punched a huge whole straight through. The whole audience gasped. It turns out the 2nd type of foam was 'trivially' different in some small way, that no one thought would be an issue at design time, but that was the composition of the bit of the foam that broke off and put a hole in the shuttle.
Now, that whole audience was an audience of engineers, and we were all shocked. We all knew that if we were asked to simulate it, we'd say 'well, it's a homogenous foam. this kind of density. this kind of young's modulus. this kind of poisson ratio. this kind of hardness. ok that'll do' and simulated with it. But these 2 kinds of foam were basically identical in all these respects, yet their behaviour was vastly and tragically different. Unless you simulate down to the sort of molecular level, simulations just don't show you this stuff.
So I understand as an outsider [I am making an assumption that you are from your understanding, apologies if you are not] why you might think that 'surely' simulation 'should' be able to be good enough 'nowadays' what with Moore's Law and MCMC and so on. But really honestly no, not to the point you're going to catch the kind of outliers that cause problems.
P.S. I'm not arguing either way on whether or not SpaceX will be safer or not than some marker. I'm sure they'll have among the safest launch vehicles ever flown. But my points so far have been 1) Beware people putting numbers or otherwise strong claims on reliability and 2) I've been trying to kick the tyres of the mental tools and reasoning people from a software background bring to bear when trying to understand things like space hardware. There is a lot more to it.