It’s been awhile since I’ve had the opportunity to update what we’ve been doing for the J-2X development test campaign. So, everyone is probably wondering where we stand. Well, if possession is nine-tenths of the law, then J-2X IS THE LAW for the NASA Stennis Space Center A-complex! Right now, the J-2X development effort has our PowerPack Assembly 2 in test stand A-1 and Engine 10001 has been reinstalled on test stand A-2.
Below are two pictures of the J-2X PowerPack Assembly 2 (known as PPA2) taken from different perspectives. In the second one, you can see that several pieces are coated with ice. That’s obviously a picture with cryogenic propellants loaded in the ducts and turbomachinery. In other words, to use our local jargon, in the second picture PPA2 is chilled down.
Well, you saw in a previous blog article that we spun up the PPA2 and we demonstrated ignition of the gas generator. Beyond that, however, we’ve had a few hiccups. For the first test intended to get to mainstage operation, we didn’t get very far. We effectively demonstrated again the spin start and ignition of the gas generator. Immediately beyond that, just a few tenths of a second in fact, the test shut down due to an issue on the facility side. As I’ve described before, the PPA2 is kind of an odd beast in that it’s a half-engine and half-facility test article. In this case, a facility valve did not function the way that it was supposed to. It was sluggish. A subsequent investigation into the facility hydraulic system identified and fixed the issue so we were again all ready to go.
On the next test we got a little farther but just before getting to mainstage, we busted an engine-side redline limit and had to shut down early. The reason for that early cut was actually quite analogous to the early cut we had on our first attempt at a mainstage test for Engine 10001. We didn’t quite understand the characteristics of the engine components and so, as we powered up the system, we were headed towards an operating point different than we’d intended. In other words, our calibration was a bit off. The redline system identified this situation and, properly, cut off the test before anything damaging might occur. While early cuts are sometimes a pain in the neck, we have those safety systems built in there for a reason. There is always a substantial and meaningful difference between a nuisance and something potentially worse.
Over the course of the next couple of PPA2 tests we once again proved that hydrogen is a pernicious rascal. This is something that has been proven on many former occasions throughout the history of rocket engine development. If you give hydrogen any opportunity to leak, any at all, it will. And sometimes, it will only leak when the system is chilled down so that when you’re checking out the system before a test, when you’re searching for potential leaks, you don’t see a thing. But then, when you are all set up and get the test going, ta-da, you suddenly have a fire. Why a fire? Because with a hydrogen leak around all the rest of the hot stuff going on with the test, a leak almost always becomes a fire. And, because pooled, un-burnt hydrogen is a potential detonation hazard, we also have devices all around the vicinity of the test article designed to make sure that any leaked hydrogen gets burnt. So, quite simply: hydrogen leak on engine test = hydrogen fire on engine test. The fires that we saw on these two tests were not on the “engine” half of the PPA2 test article per se. Instead, we got fires on the facility half. The emergency systems in place for such issues include cameras and temperature probes so that there was practically no damage and our hardware is just fine. But the fires did mean that we’ve accumulated only a limited amount of mainstage data so far.
Undaunted, we have investigated and, we believe, solved the issue and will once again be ready for testing in the near future.
On the other test stand, specifically stand A-2, the folks at the NASA Stennis Space Center have been darn busy. If you go back a couple of months in these blog articles you’ll find a discussion about the next phase of testing for J-2X development engine 10001 (E10001 for short). In that article, I tell you all about the test stand passive diffuser and the engine nozzle extension that we’ll be testing. Well, the first thing that we had to do to make this next phase for E10001 possible was to modify the test stand. In order to make the passive diffuser function properly, you have to effectively seal off the top.
In the picture above you’ll see what’s called the clamshell. This two-piece device rotates out of the way for access to the engine between tests but during a test wraps around the nozzle of the engine on the top side and connects to the diffuser on the bottom side. We’ll use a rubber-ish seal in the gap between the clamshell and the nozzle to maintain the seal while accommodating movement of the nozzle during hot fire testing. Getting this thing designed, built, and into the stand was a heck of a lot of work. The folks who accomplished this deserve mucho kudos.
So, that’s the test stand side. Next, there is the test article side, i.e., the engine itself. Because the nozzle extension is not structurally beefy enough to support the rest of the engine, the installation of the test article into the stand has to be performed in two steps. First, you install the main part of the engine and then, once that’s in place, you install the nozzle extension.
By the way, while it sounds easy enough to simply bolt the nozzle extension into place on the end of the nozzle, it’s actually a bit more complicated. While both pieces are designed to be exactly round, nothing is truly exactly round, especially not pieces of hardware this large. We have to use special “rounding” tools during the mating process. It’s sometimes amazing to think about all of the specialized tools and equipment that you need, in addition to the engine itself of course, just to make the engine work.
So, that’s where we stand in terms of our development test campaign. As if southern Mississippi isn’t hot enough in the summer, J-2X will soon be adding even more heat from two active test stands very, very soon and for several months to come. Elsewhere, FYI, we’re working on various stages of fabricating and/or assembling J-2X development engines 10002 and 10003. They will be what follows PPA2 and E10001 into the test stands. In other words, there’s lots of excitement yet to come.
One of your test descriptions said that an automatic shutdown occurred due to a calibration error. Are copies of the test engine manufactured with enough precision to ensure that, once correct calibration is established, all other test and operational engines will perform identically?
@Steve: Excellent question!
Before we ever assemble the engine, we have lots and lots of little calibration activities. We make sure that valves move like they’re supposed to. We make sure that injectors and cooling jackets have flow resistance values consistent with predictions. We perform torque checks on the turbomachinery to make sure that they will spin as expected. All of the instrumentation is independently calibrated and the software is put through its paces.
So, in theory, when we get to the engine assembly level, given all of the component and subsystem checks and given our analytical models, we ought to be able to get close to having the whole engine calibrated. And we do get close right out of the box. Considering how many pieces a rocket engine has and how tight the calibration is that we’re attempting to impose, it’s actually quite amazing how close we generally get right out of the box. But we rarely get it exactly right.
Remember, Engine 10001 is the first J-2X engine to ever exist. PowerPack Assembly is the first (and only) powerpack of J-2X hardware to ever exist. So, being a bit off of engine-level calibration (power level and mixture ratio) shouldn’t be too surprising. As we build and test more engine samples we’ll build a database of parameters that will help us get better and better right out of the box. However, even with rocket engine programs that are decades old, we often have one or two tests dedicated to engine calibration for a new engine off the production line.
I have a question which has absolutely nothing to do with this blog entry but here goes anyway.
I was watching a BBC docu-drama a while back called “Space Race” (not hard to guess the subject matter). They got to the bit where the Soviets are contemplating building the world’s first large multi-engine vehicle, and it’s made clear that this was a big step into the unknown.
So: when you’re working on J2-X, do you have to take into consideration the fact that it might be clustered (?terminology)? Obviously the original was for the Saturn second stage, but my understanding is that the SLS won’t require clustering for the J2-X. Does that make your life easier?
@Alex: The short answer to your question is this: Yes, we need to consider whether the engine that we’re developing will be clustered. The natural question beyond that is, why?
One of the “nice” things about rocket engine development is the fact that, for the most part, the engine is its own worst enemy when it comes to induced environments. A rocket engine like J-2X has bitterly cold things and terribly hot places and spinning things and rumblings things. It is extremely noisy and shakes the heck out of itself even when it’s running perfectly normally. So, if you can get the engine to survive its own environments, then for the most part, anything else you want to do to it along these lines is just fine. This is why single-engine hot-fire testing is such an integral and critical part of rocket engine and launch vehicle development.
But there are exceptions to this general rule and, in certain circumstances, clustering can represent an impact.
For J-2X (and a number of other, similarly configured engines), the particular issue is the nozzle extension. While the upper portion of the J-2X nozzle is actively cooled (regeneratively-cooled with hydrogen running through the brazed tubes that form the wall) the lower portion, the nozzle extension, is cooled by a combination of film cooling and radiation. The latter, radiation, simply means that heat is carried away as pure energy, from a hot thing (the nozzle) to a cold thing (the cooler exterior). If, however, there is no “cold thing,” i.e., no cooler exterior, then the heat cannot escape. If you have two hot nozzle extensions effectively “staring” at each other, then you cannot rely on radiation cooling and you’ve got a problem. So, if we want to cluster J-2X, we need to shorten the nozzle extension a bit since it’s only the very last bit that truly depends upon the radiation effect. This costs us some specific impulse performance, but if that’s what the vehicle designers want in terms of thrust, then it can be accommodated.
Beyond the specific consideration of a nozzle extension, the issues of clustering engines primarily fall to design aspects for the stage. The plumbing required to go to one engine is, of course, a whole lot more simple than the plumbing needed to feed three or four or five engines. You’ve got propellants and secondary fluids for pneumatics and/or hydraulics and tank pressurization flows and electrical and data connections. With multiple engines, you likely need multiple thrust vector control mechanisms to gimbal the engines to provide vehicle control. Again, more plumbing and more mechanisms. As things get more and more complex, you have more and more parts. And every time that you add a part, you add something that could malfunction. Also, as you add complexity, you add the need to further ensure that you’ve wrung out the system via an extensive test program just so you understand potential interactions.
So, in short, on the engine side of the interface, there are generally just a couple of issues to consider with regards to clustering. But on the stage side of the interface, there’s lot and lots of more stuff to consider. It is definitely one of the areas for very early trade studies when you sit down and start to design a launch vehicle. What engines do you have versus what engines do you have to develop? Can I get the performance out of some combination of current engines or do I bite the bullet and start a development effort? What issues do I have with regards to combining and clustering engines versus the issues associated with using or developing larger engines? There is never a single, “right” answer. There is almost never a single, “best” answer. You do your best to find something that works (…and fits your budget …and fits your schedule).