A question on liquid propellant as it relates to stage size and fuel weight. . .

In article ,
Christopher M. Jones wrote:
...The first stage is,
obviously, an important piece, so test it thoroughly on its
own. Hell, run flights with it and with dummy upper stages
which are just dead weight for proper balance and the tiny
bit of sophistication necessary to let the first stage do
its thing...

Bad idea, actually. The Saturn V went for all-up testing not just because
they were in a hurry, but because it made sense technically. It's quite
difficult to fake an upper stage well enough for things like vibration
properties without building something quite close to a real upper stage...
so why not fly the real thing? And if you're flying the real thing, why
not plan a bonus experiment -- assuming the first stage works -- of firing
up the second stage and seeing if it works?

One of the big changes made to Apollo in general after the fire was a firm
policy of minimizing the number of different configurations soaking up
engineering effort. The final configuration is necessary anyway, so every
non-final configuration you analyze, build, and test diverts effort and
attention from the one you really care about.

(More recently, during MOST planning we got the same message -- although
in relation to satellites rather than launchers -- from some of the Amsat
folks: forget about faking up hardware simulations of stuff that isn't
ready yet, unless it takes almost no effort; concentrate on getting the
first iteration of the real hardware running ASAP.)

This is not, repeat *not*, the same thing as cutting corners on the
testing, or worse yet, eliminating testing and putting valuable payloads
on the very first one. Nor is there any conflict with doing incremental
testing -- you incrementally test the final configuration (or one that's
as close as you can come to it, anyway), not some half-fake lashup.

...Planning a robust system to deal with failure, to
*expect* failure and to plan for it shows maturity and
experience.

The downside of this is that if you plan for failure, you will be unable
to exploit success. It's important to be *prepared* for failure, but you
should also be ready to push success to its limits. The first Saturn V to
fly tested all three stages *and* got radiation data and a high-energy
reentry test out of the Apollo on top. The one respect in which its
hardware was unrealistic -- a crude fake LM -- came back to bite them on
the second test, where the fake LM got more realistic and trouble struck
as a result.
--
MOST launched 1015 EDT 30 June, separated 1046, | Henry Spencer
first ground-station pass 1651, all nominal! |

"Henry Spencer" wrote:
Bad idea, actually. The Saturn V went for all-up testing not just because
they were in a hurry, but because it made sense technically. It's quite
difficult to fake an upper stage well enough for things like vibration
properties without building something quite close to a real upper stage...
so why not fly the real thing? And if you're flying the real thing, why
not plan a bonus experiment -- assuming the first stage works -- of firing
up the second stage and seeing if it works?

First, there are different issues at play at different stages
(pardon the pun). If your first stage is having trouble, you
know, by blowing up or otherwise performing catastrophically
most of the time, well that might mean there are some very
basic bugs to be worked out. And in that case you really ought
to test individually. You get more tests per dollar and you
get enough breathing room to get the basics ironed out. Once
you have the basics down then you can go for integrated testing.

The problem with your logic is that each step is small but
together they are deadly. Yes, why not just make the fake
stages real stages? Yes, why not, if you're going to launch
a whole vehicle, do something useful? Add it all up and you
end up a lot farther away from where you started than you
thought. And what ends up happening is that much more effort
has to go into making sure that each piece has the greatest
probablity of working *before* testing as possible, and that
costs huge amounts of time and effort (and thus money).

It's a similar chain of logic as that which justifies the
"bigger, slower, more expensive" old style space science
missions. The logic starts very sensibly with the notion
that any interplanetary mission is going to be risky, so
why not try to minimize the risk as much as possible? And,
of course, interplanetary missions don't come along often,
so it's best to try to do as much as you possibly can on
any one mission. And, of course, once you've raised the
cost enough to make the mission more likely to succeed and
once you've beefed up the science capabilities you've made
the craft a lot more expensive and a lot more valuable. So
you've got to cut back the mission risk (which decreases
science, but that's ok, because you can get that back with
enough money) and soaks up enough funding to make the
rarity of interplanetary missions a self-fulfilling
prophecy. But that's not the only, or the best, way to do
space science.


One of the big changes made to Apollo in general after the fire was a firm
policy of minimizing the number of different configurations soaking up
engineering effort. The final configuration is necessary anyway, so every
non-final configuration you analyze, build, and test diverts effort and
attention from the one you really care about.

(More recently, during MOST planning we got the same message -- although
in relation to satellites rather than launchers -- from some of the Amsat
folks: forget about faking up hardware simulations of stuff that isn't
ready yet, unless it takes almost no effort; concentrate on getting the
first iteration of the real hardware running ASAP.)

A very valid point. But not infinitely so. I maintain that
the relative dearth of first stage development is in large
part due to the absence of partial testing. It's a tradeoff
in costs. Yes, it'll cost more to build a new first stage or
a new launch vehicle from scratch, but there's also a huge
payoff. And there's also a huge disadvantage to not doing so.
Such as the aforementioned development of new upper stages for
existing launch vehicles.

And that last is a very interesting point. It really doesn't
take a hugely different amount of effort or money to develop
a new first stage as opposed to developing an upper stage,
but because of the quirky history of rocketry a hell of a lot
more work has gone into the latter than the former. To test
any stage you have to launch a whole vehicle, so there's no
advantage there to either. Similarly, in terms of success of
being able to launch a payload correctly, the failure of any
stage will doom the whole thing (though sometimes not to the
same degree).


I think you're missing my point. I'm not just talking about
*building* a vehicle, I'm talking about *developing* new
systems and new components. There are two different regimes
at play. In one you design a system on paper (or in a
computer) in its entirety and you can be almost 100% certain
that it will work as designed or very nearly as designed. In
the other you learn partly as you go, because of a lack of
experience, so you have to test a lot and you have to *change*
a lot anyway as you go. In the second, you might not even
bother designing the rest of the system, other than roughly,
until you've figured out the more important parts. Once you've
got each piece figured out then you can go and design the whole
thing and work toward making a *product* rather than an
experiment, and that you'll, likely, do all in one go. My
point is that a lot of people think rockets live in that
first category, but they don't, they live in the second, and
we just haven't roughed through the basics enough to make
designs in the first category work well. That's why they
only build brand new rockets only very rarely, and when they
do they build them as similarly as possible to pre-existing
working designs.


This is not, repeat *not*, the same thing as cutting corners on the
testing, or worse yet, eliminating testing and putting valuable payloads
on the very first one. Nor is there any conflict with doing incremental
testing -- you incrementally test the final configuration (or one that's
as close as you can come to it, anyway), not some half-fake lashup.

It really depends on the cost of different configurations
and the costs of launching. And that, I think, depends a
lot on where you decide to put your eggs. On the one hand
you can spend a lot of money to have a lot of engineers
picking over every little detail of every aspect of every
launch (which, incidentally, is a huge reason why different
configurations cost so much money), have a few launches,
and few failures. On the other hand you can have lower
overhead but, likely, a higher failure rate during testing.
Either way I think you end up at the same place. Although
with the latter I think there's more of a chance of doing
so faster and better armed. I snipped the Saturn V stuff,
which was interesting, but I'll note that the only reason
they got "bitten" by crude stand-ins was because launches
were rare and expensive. Even with a Saturn V class
vehicle I don't see much reason why they should or need to
be.

Anyway, I think your point about "incrementally testing
the final configuration" is closest to my sentiments, with
the above caveats about the difference between development
and design, of course.

In message , Henry Spencer
writes

(More recently, during MOST planning we got the same message -- although
in relation to satellites rather than launchers -- from some of the Amsat
folks: forget about faking up hardware simulations of stuff that isn't
ready yet, unless it takes almost no effort; concentrate on getting the
first iteration of the real hardware running ASAP.)

This is not, repeat *not*, the same thing as cutting corners on the
testing, or worse yet, eliminating testing and putting valuable payloads
on the very first one. Nor is there any conflict with doing incremental
testing -- you incrementally test the final configuration (or one that's
as close as you can come to it, anyway), not some half-fake lashup.


I have a horrid feeling that European designers haven't learned either
lesson. I gather that Beagle 2 went through some drastic redesigns
before the final version emerged, and as for putting valuable payloads
on the very first one, Cluster comes to mind.
--
"Roads in space for rockets to travel....four-dimensional roads, curving with
relativity"
Mail to jsilverlight AT merseia.fsnet.co.uk is welcome.
Or visit Jonathan's Space Site http://www.merseia.fsnet.co.uk

On Sun, 27 Jul 2003 09:41:15 +0100, Jonathan Silverlight
wrote:

I have a horrid feeling that European designers haven't learned either
lesson. I gather that Beagle 2 went through some drastic redesigns
before the final version emerged, and as for putting valuable payloads
on the very first one, Cluster comes to mind.

....You know, what's really going to be funny is when you have Limey
schoolkids learning about Beagle 2, and going "Hey! What happened to
Beagle *1*??"

Then again, we still ask, "Jupiter *2*???"


OM

--

"No ******* ever won a war by dying for | http://www.io.com/~o_m
his country. He won it by making the other | Sergeant-At-Arms
poor dumb ******* die for his country." | Human O-Ring Society

- General George S. Patton, Jr

In article ,
Jonathan Silverlight wrote:
(More recently, during MOST planning we got the same message -- although
in relation to satellites rather than launchers -- from some of the Amsat
folks: forget about faking up hardware simulations of stuff that isn't
ready yet, unless it takes almost no effort; concentrate on getting the
first iteration of the real hardware running ASAP.) ...

I have a horrid feeling that European designers haven't learned either
lesson. I gather that Beagle 2 went through some drastic redesigns
before the final version emerged...

In itself, this is not inherently bad...

and as for putting valuable payloads
on the very first one, Cluster comes to mind.

Arianespace gets a lot of criticism for that, which I think is only partly
justified. Cluster got a large price break for taking a chance on the
first launch, and indeed the Cluster program could not afford to pay full
price for an Ariane 5 -- it was *designed* around the opportunity for a
cut-price risk-sharing launch. (And yes, this had design implications,
most notably the fact that the satellites needed extra maneuvering
capability, because they were to be dropped off in an orbit that suited
the launcher test rather than the Cluster mission.) Note that when
Cluster 2 rose from the ashes (or the swamps :-)), it did not fly on an
Ariane 5, but rather used a lower-cost launch option that wasn't available
at the time when the original mission was put together.

On the other hand, I do think Arianespace deserves part of the blame for
that mess, because they were far too optimistic about reliability. Had
they been honest and realistic, Cluster might not have flown with them.
--
MOST launched 1015 EDT 30 June, separated 1046, | Henry Spencer
first ground-station pass 1651, all nominal! |