Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
NASA Technology

How NASA Brought the F-1 Rocket Engine Back To Life 221

First time accepted submitter Martin S. writes "How NASA Engineers have reverse engineered the F1 engine of a Saturn V launcher, because: 'every scrap of documentation produced during Project Apollo, including the design documents for the Saturn V and the F-1 engines, remains on file. If re-creating the F-1 engine were simply a matter of cribbing from some 1960s blueprints, NASA would have already done so. A typical design document for something like the F-1, though, was produced under intense deadline pressure and lacked even the barest forms of computerized design aids. Such a document simply cannot tell the entire story of the hardware. Each F-1 engine was uniquely built by hand, and each has its own undocumented quirks. In addition, the design process used in the 1960s was necessarily iterative: engineers would design a component, fabricate it, test it, and see how it performed. Then they would modify the design, build the new version, and test it again. This would continue until the design was "good enough."'
This discussion has been archived. No new comments can be posted.

How NASA Brought the F-1 Rocket Engine Back To Life

Comments Filter:
  • by T.E.D. ( 34228 ) on Monday April 15, 2013 @10:05AM (#43451643)

    I mentioned this in a comment last week [slashdot.org]. Manned spaceflight in the USA is essentially a matter of history, not something we know how to do today. If we wanted (for whatever reason) to go back to the moon, we'd bascially have to start over from scratch. It would probably take as at least as long as the original Apollo program, and cost far more.

    After the fall of the Roman empire, knowledge of concrete was lost, and for about 500 years Europeans were walking around Roman buildings and upon Roman roads that they had no idea how to recreate. Right now all our Apollo engineers are dead or dying, and the Astronauts will soon follow suit. Soon there will be no living human who has set foot on another world. Then we will know just how those Medieval Europeans felt when we go look at our old Apollo relics in the museums.

  • by CAIMLAS ( 41445 ) on Monday April 15, 2013 @10:22AM (#43451765)

    You know, we used to call it simply, "engineering" - back before business school type managers stuck their dicks into the soup and soured the pot for everyone.

  • by Geoffrey.landis ( 926948 ) on Monday April 15, 2013 @10:34AM (#43451909) Homepage

    This flies in the face of at least history. It also flies in the face of the usual mythology that NASA invented the computer. Which is it?

    NASA didn't invent the computer. However, in the 1950s computers were room-sized assemblies of hardware. NASA and the Air Force were the only two entities that needed computers that were smaller than that (the Air Force to put in missiles, NASA to put in spacecraft). The Block I Apollo computer was the driver for integrated circuits, and hence the grandfather of all of today's desktop computers (called "microcomputers" back in the old days, when "non-micro" computers meant the Univacs and 1103 and the other big iron of the day.
    http://www.computerhistory.org/semiconductor/timeline/1962-Apollo.html [computerhistory.org]

    They had no computers, or they invented them?

    Both.

    It's neither, actually. But by 1963 manufacturing, at least for the money-means-nothing military, was already computerized.
    http://www.youtube.com/watch?feature=endscreen&v=_1g1b_EeVHw&NR=1 [youtube.com]
    Why do you think it's called "numerically controlled" and not "digital"? It's because the whole concept is so old that the wording has had time to become obsolete.

    The comment you're responding to was about computer design tools--CAD--not about numerically-controlled milling machines. And for that matter, the numerically-controlled milling machines of 1963 weren't really what you would call general purpose computers.

  • Concrete was a useful technology. I'm not sure that's true of manned space flight. For a fraction of the money you can send a robot.

    Sure, a robot is cheaper, but you get what you pay for. Steve Squyres (you know him, he's the guy in charge of Spirit and Opportunity) once noted that what the rovers had accomplished in five years could have been done by humans in a mere five days. (In fact, the total mileage covered by both rovers is less than one days traverse by one of the lunar rovers.) Robots are great when you want to mindlessly collect great heaping mounds of the same data, day after day... But at anything much more than that, they're still far inferior to people. (Which is why all three rovers to date aren't actually robots - they're teleoperated.) And there's nothing on the horizon to think that'll change anytime soon.

  • by Anonymous Coward on Monday April 15, 2013 @11:06AM (#43452217)

    The Saturn V was designed with paper and slide rules, and very little computer work.

    As far as circuit simulation goes, ECAP is probably the first full circuit simulator. I have a copy of the manual for the 1620 version, but it's dated 1970, but there are earlier versions. All written in FORTRAN. I'll bet that almost no computer simulation was done for the electronics on the Saturn V.

    For thermal and mechanical FEM analysis, NASTRAN started in 1964 and was delivered in 1968 Not used for Apollo, but used for Shuttle.

    Drafting wise, Sutherland's Sketchpad was in 1963, and was pretty much the first "drawing" tool on a computer, and it used custom hardware, and was hardly usable for actual drafting.There were some specialized tools for splines and such in the car industry, but "real" drafting on a computer probably didn't exist until the 70s. (Drafting or Technical Drawing was still a course you took in high school in the mid-70s.)

  • by ebno-10db ( 1459097 ) on Monday April 15, 2013 @12:26PM (#43452999)

    What they did back then, and what they call "process" today, are two different things. Talk to some old timers. Here on Long Island I've met guys who worked on the LEM (built about five miles from where I grew up). Every engineer hates documentation, but good engineers appreciate that a certain level of formal specs and documentation (of designs, test procedures and test results) are necessary. There's an easy way to determine whether documentation serves a purpose or is just horse shit. Put yourself in the place of some poor slob picking up the documentation 5 or 10 (or even 50) years from now, and decide whether reading what you're writing would be useful to them. If it would be, it's useful. If you'd skip over it as something that was judged by how much it weighed, it's garbage.

    I'm mostly a hardware guy. I've worked in places where the documentation was awful and caused many problems. I've also worked in places where there was endless procedure and process, and while the documentatin weighed enough to satisfy project managers and process fetishists, it was often wrong. My favorite was when I worked for a small East Coast subsidiary of a large West Coast (LA area) company. There was a heavy mil influence at the parent, and every drawing had more stamps, signatures and dates than the Declaration of Independence. It was also often wrong. Sometimes I'd hit a schematic I couldn't figure out, and feeling like an idiot, call the designer, only to have him tell me he knew it was wrong! Meanwhile our garage shop (50 people tops) had dead nuts accurate documentation. In some cases I had things like cable drawings on a piece of scratch paper, but they were accurate, had the proper revision and approval info, and were properly logged into documentation control. Ask for the complete set of drawings for one of our satcom terminals, and you'd get a copy of it. The right rev and completely accurate. Documentation and procedures (oops, I mean process) has gone from something that's a means to an end, to a fetish that justifies the existence of buzzword spouters. ISO9000 anyone?

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Working...