CRS-7 Launch Update
spacex.com"Cause still unknown after several thousand engineering-hours of review. Now parsing data with a hex editor to recover final milliseconds."
4:09 AM - 29 Jun 2015
Ugh, now imagining trying to debug a really sneaky bug that costs $100 million every time it triggers...
I recommend Henry S.F. Cooper's book _The Morning Star_, which is about debugging hardware failures and OS race conditions on a spacecraft orbiting Venus.
(There are similar stories about debugging stuff on the various Martian rovers, but Cooper's book is a very good treatment...).
It's actually "The Evening Star"
Grab it used for $0.75 http://product.half.ebay.com/The-Evening-Star-Venus-Observed...
I think you mean The Evening Star, marvelous book: http://amzn.to/1Hq8TcX
I stand corrected. Written in haste.
Cooper is a wonderful writer, I've got all of his books :-)
Stupid question perhaps, but don't we have the ability to 100% simulate the rocket physics and the code it runs on in a simulation environment? Or are they just punching out code, shoving it onto rocket controllers, and testing in the real world?
I'm curious as to the QA system used here. I imagine with proper simulation this should have been catchable. I wonder if SpaceX's low cost approach means cutting certain corners and situations like these where catchable issues make it into the wild because of the difficulty of rocketry in general with the added difficulty of cheap spaceflight tacked on.
I really hope they didn't just find themselves in a STS-51-L moment where it'll take months to truly iron out the root issues. Thank goodness there was no loss of life and SpaceX's stack isn't man rated yet.
Rocket physics are actually relatively trivial and, yes, can be fully simulated (and are). Rocket plumbing is always the hard part. Perhaps the threads on some connector got stripped as it was screwed together. Perhaps there was a manufacturing flaw or unexpected bit of corrosion in a particularly vital bolt. Perhaps a bit of contamination in a fuel line caused something catalytic to happen. Perhaps a bit of excess H20 condensation in a LOX valve caused an ice dam to form and the supply line to over-pressurise. These are the sort of problems which bring rockets down: really damned complicated plumbing problems.
I guess my point is, can we do a full simulation of every screw, material, plumbing, liquid dynamics, weather dynamics, etc and augment those with known fail scenarios and other fuzzy data to build out a real world KSP that predicts fails reliably? We should understand how things like corrosion and condensation work on a rocket engine. Considering the low cost of incredible amounts of CPU power, granular level simulation is possible on a certain level today if someone wanted to create it. We certainly see this kind of thing with stealth technology, where we can simulate every permutation of near every radar photon hitting the various surfaces of planes with various materials, scenarios, temperatures, etc.
I imagine this level of simulation might not be entirely feasible yet. Maybe for the lack of trying or budget. In a growth industry or one powered by both commercial and technical pressures, it may be difficult to sit down and build something like this out. From a more practical point of view, it may make sense to just let things explode than spend years running expensive simulations instead of building things, launching, and collecting paychecks.
I think a critical part of his point is that what you build and what you model are neccessarily two different things. You can totally simulate it, and then when the rocket inevitably fails, you can go "aha! This bit deviated from the simulation!" But you can't feed that forward beforehand to prevent the failure, since you can't expect random acts of poor workmanship or crafting. You can only prepare and hope (and you can do that with shockingly high confidence - but rockets are more than equally shockingly complex.)
Part of what makes the idea of bringing the first stage back to the pad so important is that we so rarely get to use the same engines multiple times in the field (where all the really nasty reality checks are done). Being able to reuse stages allows us to far better model how they will perform in the future. Otherwise, we're using test beds to feed parameters into sims to inform our launches; it's good practice, but more physical evidence is always better.
This.
Engineering is what hopefully guides reality up the correct branch of a theoretically possible tree.
You can simulate most of each one of those branches. But what are you going to do with a million simulation results? How does that guide your course of action? What do you do differently?
If this was an engineering or assembly defect, the answer is always going to be "Don't do that next time." If it was a design defect, then the part wasn't simulated (unlikely) or our understanding of how it operated in this design was incomplete (more likely).
The trick with rocket science is that the design tolerances are by necessity very tight. Physics dictates this with chemical propulsion. Every part you over-engineer in a weight-increasing way decreases the weight available for payload. And there isn't very much weight there to start with...
The issue is that rocket physics (essentially Newton's laws of motion) are for the most part first- and second- order, linear, ordinary differential equations with exact solutions. The plumbing, on the other hand, is governed by fluid dynamics, heat transfer, and the like. These are systems of complicated partial differential equations without exact solutions, requiring numeric methods.
>I guess my point is, can we do a full simulation of every screw, material, plumbing, liquid dynamics, weather dynamics, etc and augment those with known fail scenarios and other fuzzy data to build out a real world KSP that predicts fails reliably?
Frankly, no. You're wildly underestimating the complexity of the system.
The radar technique is possible because of the trivially-parallizable finite-difference time domain method, which most certainly does not simulate every photon (this may have been a rhetorical flourish on the part of wherever you learned this; FDTD curiously has zero error term). Nor would it simulate a wave hitting from every direction; each of those would be a separate run of the simulation.
no, we can't. we currently do not have the CPU power to do molecular simulations of fluids and solids (beyond the grain level) at large scales, that's why we still have supercomputers working at simplified versions. additionally, we don't have 100% fidelity in knowing environmental conditions, what the weather is doing at that exact point, the exact velocity/temp field of the atmosphere (which is constantly changing) at the molecular scale, which would be essential for a 1:1 simulation.
A lot of simulation already happens but simulating every imaginable scenario is impossible.
> I imagine with proper simulation this should have been catchable.
We don't know in this specific instance, but generally this is just fundamentally not true. You're way over-estimating the abilities of computers and way under-estimating the complexity of these systems.
I haven't been down voting your comments, but if I had to guess as to why other people are, it's because comments like this are typical of a certain kind of arrogance. I think we've all had that moment where we think "what, that sounds easy!" about someone else's problems, only to realise when we try to solve it ourselves we're suddenly confronted with that problem's true complexity. These are very smart people working on these problems, and your comments come across as if you're suggesting they've been negligent–while that could be true, it wouldn't be my first guess. Rocket science is hard, and things go wrong, and no amount of computing can change that.
I don't think we have the ability to 100% simulate anything - I don't doubt for a second that a lot of this stuff is being simulated already, and I think you may be severely overestimating just how useful any doable simulation is in terms of catching a bug like this one.
You have literally hundreds of systems working in concert and tied to more hundreds of physical components coming under extreme temperature and pressure conditions, some of which can interact in the weirdest and most unexpected ways - certainly not ones you'd always think to model. The chances that any one of those does something unexpected is not low, and the chances that it cascades into a much larger failure is non-significant.
edit: It's also sometimes a human problem - thousands of people working on this together, and all sorts of different incentives. Here's a famous example of a failure, and the PR kerfuffle that ensued: https://en.wikipedia.org/wiki/Rogers_Commission_Report
Quoth Feynman:
"It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement? Since 1 part in 100,000 would imply that one could put a Shuttle up each day for 300 years expecting to lose only one, we could properly ask "What is the cause of management's fantastic faith in the machinery? .. It would appear that, for whatever purpose, be it for internal or external consumption, the management of NASA exaggerates the reliability of its product, to the point of fantasy."
>You have literally hundreds of systems working in concert and tied to more hundreds of physical components coming under extreme temperature and pressure conditions
This is exactly what computers are for: doing hard stuff we can't do on paper or just by real world prototype testing. I imagine this is a hard problem, but it may be so because from a time/budget perspective it may just make financial sense to let stuff blow up now and again, than build out such a system.
I kinda see this as the difference between writing typical code versus writing code that's deterministic. The former is cheaper/faster but the latter is safer but more expensive and slower. In growth industries or when you have a strict schedule on your back, the slower approach is often ignored.
>Quoth Feynman
Feynman died when the hottest CPU was the 386. We simply have the capabilities, at least in hardware, for non-trivial simulation that during Feynman's time would have required CPU resources ridiculous to even speculate about. Safe assumption in Feynman's world (1918-1988), at least in regards to technology and engineering, may not be safe assumptions in our world. The same way our assumptions today won't make too much sense for our grandchildren. They might be bewildered by the idea that rocket fails were constant and common, the same way I'm bewildered by things like hot-days causing vapor lock to shut down old cars or, say, occasionally tuning a carburetor. We have electric gas pumps and computer controlled fuel injectors now.
edit: to reply to jacquesm. That's a pretty bold claim about O-rings. We fully understand the materials they're made of, their typical decays, etc. They're not magic. If someone wanted to make a top-down simulation that included, well, everything, it certainly seems possible to me, and while certainly not perfect, if done right, should provide positive outcomes. The real question is, what's the incentive? Spend billions and years doing this for one system (which may be old or even obsolete by the time the simulation is complete) or just accept the occasional preventable loss. Seems the latter approach just makes more sense financially, but that doesn't mean the former approach must be impossible. Many things are possible that just aren't incentivized.
Oh gosh, having worked on a fairly large vacuum system, I can tell you that o-rings are monsters. Very minor errors in dimensions can mess up the seal, and temperature/humidity/wear/elasticity and all that can subtly mess with the dimensions in crazy nonlinear ways. You can simulate the ever loving garbage out of it and an imperceptible change in composition due to an undetectible mixing error when extruding the ring can cause a seal to slightly leak. Mayhem ensues. (And most likely any attempt to directly detect it will destroy the integrity of the o-ring or take so long to render the test useless, since there are usually hundreds of o-rings (or in the thousands - o-rings are all over the place).)
I'm not even talking about jackquesm's note about the failure mode, either. Just real insidious errors in manufacturing that can't be detected in any sort of reliable, sane way. Even the Challenger's o-ring wasn't guaranteed to fail, and indeed most didn't. In fact, most of that entire o-ring didn't fail.
I've seen some really freaky things amplify what are essentially chaotic edge cases. You can certainly figure them out, but you'd never get anything done for any level of affordability in time for any ship date if you didn't just calculate risk and go ahead.
TL;DR: risk is always there because the world's imperfect. At best you just tighten the statistical confidence, but that's super hard.
Faster computers do not equate to magically better programs and/or programmer capabilities. The computers from Feynmans days could do finite element analysis and structural simulation on grids fine enough for just about all engineering work. It's the execution details that get you (such as an O-ring...). And nobody simulates the execution in a meaningful way simply because there isn't enough data to start your simulations with. These are human failures first, process failures second.
The problem with simulating failures is that there are an infinite number of them. Should you simulate the effects of omitting each individual molecule in the whole assembly? Or adding one of every possible contaminant molecule at every possible location? What about more than one? It's a combinatorial impossibility.
> but don't we have the ability to 100% simulate the rocket physics and the code it runs on in a simulation environment?
No, we don't. While we can do this very well for the "high level" physics, we can't do it very well for the "low-level" physics such as -- for one example -- the detailed effects of turbulent flows (both outside of the craft and inside of the plumbing), which are usually modeled based on averages of aggregate effects and random models because a detailed deterministic model is impractical (both, IIRC, because doing so at the level we could in theory do is too computationally expensive to do in practice, and because even our theory is pretty limited when it comes to turbulence.)
> I imagine with proper simulation this should have been catchable.
Its possible that there is some level of simulation which would have caught this (we won't know unless they figure out with enough detail what the problem was), but even if it would have been possible, it may not have been cost effective.
I recall John Carmack mentioning that they tried fluid dynamic simulation with their rocket motors. It got them a general idea of how the motor would perform, but in real life the performance of the motor was significantly affected by small changes in e.g. the quality of the welds in the combustion chamber.
The book The Martian, big-budget movie coming soon, has some pretty awesome fictional-yet-very-well-informed situations of things that were so unimaginable to have an impact on anything and still caused things to go terribly wrong. Highly recommended.
Science has yet to discover the ultimate physical laws that govern the universe so 100% simulation is still impossible even in theory. In practice high fidelity simulation is still hard. Here's a video about the state of the art in combustion chamber simulation and what it's current state is:
Fluid dynamics is still very hard to simulate, and that's where rockets go wrong.
After watching the press conference yesterday I got the sense that Musk's tweets aren't particularly helpful for SpaceX press relations
The thing is -- despite all the "Iron Man" winks and glamour of being a billionaire who wants to colonise Mars, etc. -- Elon is truly, deep down, a nerd's nerd. Which means that his respect for the PR department is probably roughly proportional to how much duct tape they've wrapped around his head.
The PR effort in this case was being lead by Gwynne Shotwell who is the President & COO. He was apparently tweeting information that his COO wasn't prepared to comment on yet. That doesn't send a good message about leadership confidence to people in his organization regardless of how much of a "nerd's nerd" he's trying to present himself as
SpaceX was criticized after its early failures for not being transparent enough, so Musk is probably still reacting to that.
TBH, that hex editor thing sounds like bs.
Can you be more specific? If you have a partial piece of data (say because the data was streaming and a rocket exploded), the parser for that data is unlikely to work out of the box. Hence the use of a hex editor.
Yeah, but why not write your own temporary parser or whatever. They (should) have top-class software engineers in there, why they don't just make a quick and dirty script to sort out whatever they're looking for?
IDK, that tweet felt like when you're watching a movie and then the 'hacker' comes around and you see a lot of props on the screen that are designed to excite 'geeks'. Like, right now, a lot of guys should be like: "OMG OMG! They are looking at the hex code directly! Damn, that is so looooooow-level, they call it rocket science for a reason!"
Anyway, hopefully they find the problem; whether with hex editors or not SpaceX is really doing cool stuff.
Some hex editors allow you to actually define an ad-hoc data format to parse, e.g. http://www.x-ways.net/winhex/templates.html – it doesn't have to be ed(1) for hex data. Besides, it could just have been a choice of words meant to convey that they have a bunch of incomplete/corrupted data that needs manual interpretation.
How are you going to figure out how to write that quick and dirty script without looking at the raw data in a hex editor to figure out how it's been corrupted?
Far from BS, pointing a hex editor at your data dump sounds like the very first thing you'd do when you get some data that your software can't immediately read.
As a non-native English speaker, I find the omissions of "the" very prominent and interesting in SpaceX speech. "shortly before first stage shutdown", "resulting in loss of mission", "139 seconds into flight", "some period of time following separation", "data to determine root cause" -- is this a general theme in engineering or journalism? I wonder what linguists have to say about this.
In these cases the phrases are being used as proper nouns for preexisting events on the timeline. For example, I wouldn't say that I went for a walk "five minutes before the noon," I'd say "five minutes before noon." They're speaking in a jargon that treats these events the same way that you or I would talk about Monday or midnight and which also gives them precise meanings. If the main engine shut down on its own at an unexpected time then you could say "shortly before the main engine shut down." This lets you say things like "The main engine lost power 30 seconds before main engine shutdown" and be only slightly confusing rather than nonsensical.
It's standard in military debriefings (aerospace at least), especially for flight test debriefings. The flight test pilots I've worked with, mostly former U.S. Navy test pilots, all spoke like this during their debriefings and wrote in the same way for their flight logs, report-outs, etc.
Not a linguist but a writer here who loves language.
I'm seeing a lot of folks dropping articles. It's also becoming quite common to eliminate pronouns at the beginning of sentences, i.e., instead of "I went down to the store" you write "Went to the store"
I use this purposefully to jar the reader. I have no idea what the underlying linguistic reasons are.
Implied pronouns, perhaps a trend from Facebook usage? On Facebook and Twitter you have an implied "I" that makes saying you did something redundant. This could transfer over to other formats of conversation.
Other languages are a bit ahead of English in that regard, but their conjugations make it clear who the subject is.
> Not a linguist but a writer here who loves language.
You're probably demonstrating this on purpose: your very first sentence is itself an example of dropping a pronoun + verb.
This is a common trend in scientific writing. [1]
It's considered standard to write in formal, passive, third-person tone. [2]
During undergrad, I was constantly drilled to make my writings as concise as possible.
[1] http://www2.aje.com/en/education/other-resources/articles/ed... [2] http://writingcenter.unc.edu/handouts/passive-voice/
"First stage shutdown". "Loss of mission". "Flight". I'm not sure what the term for it is, but these seem to refer to generalized phases/states of flight that the mission can be in. The use of "the" would refer to specific instances of the noun that the speaker has reason to believe the listener would know about. [1]
They almost feel like "uncountable" nouns, but I'm not sure. "Flight" can be countable, but as a generalized state/phase, I think it wouldn't be. It doesn't sound strange to me (a native speaker).
It would not be wrong to use "the" for many/all of these cases, but it would have changed the meaning, somewhat.
[1] http://www.edufind.com/english-grammar/definite-article/
It's how engineers talk in this context.
Focus on the problem, not the people.
I see it like I see git commit messages. You need to convey as much information as possible in as few words as possible. Dropping articles that don't add anything to the context is a way to keep it sweet, short and punchy I guess.
Indicative of shared Russian heritage of spaceflight? ;)
"Preliminary analysis suggests the vehicle experienced an overpressure event in the upper stage liquid oxygen tank approximately 139 seconds into flight. Telemetry indicates first stage flight was nominal and that Dragon remained healthy for some period of time following separation."
Sounds like they are trying to suggest that if there had been people in the capsule they would have survived...
The manned capsule has a powered abort system, and this one doesn't, so they really don't need to suggest anything (since a failure here would not be reflective of the surviviability of Dragon2).
They intentionally disable ("safe") the parachute system during the launch phase, but from the rumors I'm hearing coming out of SpaceX, if they had been enabled, this capsule would have survived.
Maybe all the cargo shots should have these systems enabled to further exercise them. It would have been nice to demonstrate capsule survival in yesterday's event.
It's not something you merely "enable." These cargo missions are using Dragon 1 capsules, whereas the manned system is Dragon 2. The abort system in Dragon 2 is integral to the capsule (it doubles as the landing system used after a normal flight) and isn't something you can just retrofit to a different vehicle.
Can Dragon 1 have parachutes?
Yes, and it does on every flight since it's used to return things from the space station back to Earth. However an abort system also needs something to move the capsule away from the (probably exploding) rocket when something goes wrong, which is typically a strong and short-firing rocket on the capsule itself.
In this particular case, it sounds like Dragon survived and probably could have been recovered using the parachutes, but they weren't armed since survival without an abort system isn't something they really try for. It would be interesting to make the attempt, but not informative for manned flights since those will have a proper abort system.
Interesting, thanks.
It would be interesting to know if they can remotely trigger the parachutes - i.e. in this case after it had fallen a ways they could have triggered them - even just to see what would happen.
Yes, it seems likely that the capsule and at least some of the contents could have survived if they had opened the parachutes on descent. Of course, I don't know where it would have landed or how long it would have taken to get a ship out there or.... Anyway, I imagine it just wasn't in the plans for something like this.
Sorry (there was some confusion below):
Dragon 2 has a powered escape system. Dragon 1 just has parachutes for the recovery phase.
You safe the parachutes for the ascent phase because they're dangerous. If they accidentally trigger, you lose the whole rocket due to structural failure from the sudden forces. You'd most likely lose the capsule/chute at this point too.
A chance of recovering the cargo in the event of an incident like this just isn't considered worth it.
Also the first stage might have survived and returned to landing if it had known about the trouble and detached earlier? Or am I misunderstanding?
If the second stage just hadn't been there then the first stage might have survived and landed. But I'm not sure there is any way to "detach early", and you'd have the problem of having too much fuel left over in the first stage. I doubt it's designed to land in those circumstances (why would it be?), so it probably couldn't.
I think that might be a stretch but I don't think they care about that half as much.
Just after the pressure event you see Dragon being slung off the rocket... If only it was possible to deploy the parachutes during launch we could've hypothetically saved the payload.
I wonder if the launch abort mechanism on the Dragon V2 would've been of any help here too to jettison it safely away from the rocket.
I read the rocket was around maximum dynamic pressure during the event (Or just after?) and I'm not sure if it would stand such forces of a jettison during such time.
WRT max-Q its a meme that won't go away because the most "interesting" thing on the public PR timelines before the incident was max-q. However dynamic pressure drops off extremely quickly due to altitude (low air pressure) and max-Q was a good while before the incident, so it wasn't a direct issue. It could obviously be an indirect issue if something started to buckle a minute previous or shook loose and for whatever reason a minute later it burst, perhaps as pressure built up or something.
The other meme is there are or have been rockets or overall systems with flight profiles and designs that have unsurvivable portions of the flight. Or only extremely theoretically survivable. Think of the old shuttle system, for example. A RTLS abort was theoretically survivable, but lets be realistic here... However the space-x guys are extremely proud that they designed an overall system that has no unsurvivable by design flight portions, and also very proud that they did a test flight with a separation near max-q specifically to prove it would work just fine even at max-q...
One interesting problem with a structural failure at that speed is it could be hard computationally to tell the difference between some irrelevant pogo-ing or vibration vs 50 ms later half the rocket is flying sideways, at which point it might be unsurvivable. Bad car analogy is I can jump out of an airplane with a parachute at 100 MPH and all turns out just fine, but randomly getting tossed out of a 100 MPH car isn't going to likely end very well even if under ideal conditions its no big deal.
> the space-x guys are ... very proud that they did a test flight with a separation near max-q specifically to prove it would work just fine even at max-q…
The in-flight abort test for Dragon v2 is scheduled to occur later this year. It hasn't occurred yet. https://en.wikipedia.org/wiki/Dragon_V2#Flight_testing
Also note that Dragon v2 was not on this mission and won't fly to space for a while. This was a Dragon v1 mission. Dragon v1 is unmanned and has no launch abort capability.
You are completely correct that they haven't flown it. When I wrote that, I must have been thinking about the successful pad abort a couple months ago.
No, Max-Q is much earlier in the flight. They were very close to the end of the first stage burn.
> we could've hypothetically saved the payload.
As I understand it, the primary payload (the new international docking adaptor for the ISS) wasn't in the Dragon capsule itself, so it wouldn't have been saved even if the Dragon was recovered (sadly).
If it wasn't in dragon, how was it going to get to the ISS?
Sorry, I wasn't very clear–it is in the Dragon, but it's not in the pressurised 'nose' part (which I believe is the part that's jettisoned in an emergency, but I'm not actually sure about that? perhaps I'm wrong). Instead, it was in the unpressurised 'trunk'.
See this image: http://www.nasaspaceflight.com/wp-content/uploads/2014/04/Z8...
"Dragon also will use its unpressurized trunk to deliver the first International Docking Adapter to enable future commercial crew vehicles to dock to the station."
https://www.nasa.gov/sites/default/files/atoms/files/spacex_...
They've previously used the trunk for a payload on CRS-2, CRS-3 and CRS-5. You can see a video of how it works in CRS-5 here:
https://www.youtube.com/watch?v=yXfOOIYWGF8
(Really cool video by the way!)
The trunk does come with the capsule during launch abort for Dragon 2. It has fins on it to provide aerodynamic stabilization during the abort.
However, the trunk is later jettisoned, so only the capsule is recovered in the end.
http://www.spacex.com/sites/spacex/files/padabortinfographic...
My thoughts on this. Overpressure in the LOX tank could be due to 1) failure to vent properly or 2) something heating it up.
Option 1 is based on the fact that it's constantly evaporating and needs to vent. This seems really unlikely given that it passed all test on the pad 2 minutes before. It also sounds like this was likely ruled out based on Elon's tweet about a "counter intuitive cause".
Option 2 sounds like fire or flames due to fuel leakage or something, but then realize that this is the second stage and all the action is going on 100 or more feet down in the first stage. They also have a camera on the 2nd stage engine which was shown shortly before the incident and nothing was going on in there. I wonder what the in-tank camera showed.
It seem that to get the extra energy into the tank, something must have fired up early. But if there's one thing Spacex seems to have a lot of it's data. Aside from a breech letting external air in (like the last shuttle accident), how do you get enough added energy into a tank to build pressure to the breaking point? In 2 minutes.
There are plenty of other scenarios...
The IDA is the heaviest thing they have ever carried in the trunk, AFAIK. Maybe its mounting bracket failed and it impacted the top of the second stage, buckling the LOX tank. A suddenly induced crack allowed some LOX to escape (the initial 'puff'), and the suddenly reduced pressure allowed the rest of the LOX to boil off and the tank to BLEVE, causing the catastrophic failure of the second stage.
Obviously this is a completely theoretical scenario, but it's one of many I could dream up...
EDIT: While is is a fairly technical discussion, I realize I got a little heavy handed with the acronyms there...
IDA: https://en.wikipedia.org/wiki/International_Docking_Adapter LOX: https://en.wikipedia.org/wiki/Liquid_oxygen BLEVE: https://en.wikipedia.org/wiki/Boiling_liquid_expanding_vapor_explosionFalcon typically has a trunk-facing camera on top of the second stage, sometimes broadcasted during separation with Dragon. I wonder if CRS-7 had the camera? If the mount did fail, the footage could show that (assuming SpaceX successfully received the broadcast).
Example footage here: https://youtu.be/p7x-SumbynI?t=25m45s
Interpreting Musk's tweet about 'counter-intuitive' meaning BLEVE would make sense to me.
Hmm... perhaps, but that seems pretty 'intuitive' to me.
Could the mass of the IDA have introduced unexpected lateral forces that caused the second stage to buckle like a soda can under the aerodynamic pressure? And perhaps simple crushing was the cause of the tank overpressure?
I can see why you would say BLEVE. But I'm quite curious why there wasn't a huge fireball, at any rate
Oxygen by itself doesn't burn. If it was just the LOX tank that burst, there wouldn't have been anything to burn. Clearly some sort of FTS destroyed the vehicle (I don't think atmospheric forces could have taken it apart that cleanly and instantaneously), but the FTS system is probably just detcord running down the length of the propellant tanks. If the tanks were 'unzipped' quickly enough, the fuel and oxygen might not have had time to mix to a stoichiometric ratio that supported combustion.
Looking back at a gif of the incident, there was a pretty impressive amount of fire. Initially when the oxygen hit the first stage exhaust, causing the unburnt RP1 to burn (all the 'extra' flame that appears in the exhaust plume), and then there is a fair amount of fire at the front of the vehicle a second or two later (I assume the second stage RP1 tank failed at that point). Finally there is a large cloud and the rocket vanishes. That's the part that I assume is some sort of FTS, and likely blew the rocket apart with enough force that the prop didn't get a chance to mix.
Did Jack Swigert stowaway on board to do a cryo-stir?
For those who are also having issues loading the site: Nothing that wasn't already released via Twitter or yesterday's press conference.
... and people think debugging pure software problems are hard.