Impact Phase

 As I mentioned in my previous post, I have generated over 350 parameter sets that strike the Moon within one hour of the May 29th seismic event that seems to record the final impact of the ascent stage of the Apollo 16 Lunar Module Orion. Are all of these useful? What time difference should disqualify a simulation? If the simulation misses by 5 minutes, is that OK? If it misses by a full hour, is it meaningless? To answer this question, we need to dig deeper into the data, to try to understand what’s behind the time shifts. 

Let’s start with Figure 1, which is showing the distribution of impact times. Each vertical bar represents one 4-minute period, and the height of the bar shows how many of the simulations strike the Moon within that period. The red bar near the middle of the graph is the target time, around 21:14 on May 29th, 1972. The height of that bar is 30, meaning that 30 of the simulations impact within that 4-minute window. Overall, this set is centered about 6 minutes later on 21:20, and the impacts cover a total time span of 90 minutes. 

Figure1: Distribution of impact times from my simulation set. The red bar is at the time of the recorded impact event, and 30 of the simulations strike the Moon within that 4-minute window.

If you read my earlier post about “nudging” the orbits closer to a target impact time, you might be wondering…why not continue nudging until all the impacts occur at exactly the right time? The reason is that nudging stops working once you get the impact within one orbital period of the target. Huh? Let’s say the period is exactly 2 hours. (It’s close to that.) And let’s say we have a case where the impact is early by 2 hours and 20 minutes. We nudge the VMAG parameter a bit higher and re-run the simulation. Sure enough, this time Orion skims over the impact point, and zooms around for an extra revolution…then slams into the Moon two hours later on its next pass. Now, instead of being 2:20 early, it’s just 20 minutes early. Unfortunately, further nudging barely affects the 20-minute miss. In fact, another nudge might push the impact out by another 2 hours, making things worse.

We need to work with the impact times we have. Maybe we can understand what’s driving those offsets in the impact times? Let's call it impact phase. Once again (as has happened over and over during this investigation) the answer becomes obvious once the data is viewed in the right way. Take a look at Figure 2, which compares the “miss” time, in minutes, versus the initial orbit period in seconds. Aha! Notice that a one second increase in the orbit period shifts the impact time by about 7.2 minutes…or about 430 seconds. If Orion struck the Moon on May 29th, it would have been on about the 435th revolution around the Moon since jettison. So, a one second increase in the period means that 435 revolutions later, it has fallen behind by 435 seconds. And that is exactly what we see in Figure 2. Slower orbits mean later impacts, and vice versa. Impact phase is controlled by the orbit period.

Figure 2: Time offsets from the target vary linearly with the orbital period. It makes perfect sense!

(Another very interesting thing about Figure 2 is that it gives us a great way to validate that the May 29th seismic event was actually Orion. If we knew exactly the orbital period of Orion, we could confirm that it lines up with the observed impact time. I have looked for sources that could confirm Orion’s orbital period without success. Do you have any references? Please leave a comment.)

But now let’s get back to the original question. If a given simulation misses the impact time, can it still be useful to predict the impact location? One way to answer this is to take a given parameter set, and tweak it so as to vary its period, shifting the impact time, and then take a look at how the impact location moves around. Dramatic position shifts would mean we should ignore those simulations that aren’t close to the right time. Modest shifts would indicate that the exact time of impact is not so critical.

Figure 3: A sweep of one parameter set, to vary the impact time. Although the impacts are spread over a range of 2-plus hours, the impact locations are all within 1.4 km of each other. 

One way to change the orbital period is to raise the orbit, so that is what I’ve done in a set of simulations shown in Figure 3. You see that the RMAG parameter (the distance from the center of the Moon) is gradually raised to 1849.2 km. The VMAG parameter has been “nudged” to bring the impacts within one orbit of the target time, while all other parameters are held constant. Notice the impact locations. They remain in a tight pattern centered around 104.3 °E, near 10 °N. These locations are all within 1.4 km of each other, despite the fact that the impact times go from 84 minutes before the target to 53 minutes after. 

From this, I conclude that I need not be too concerned about impact time shifts of less than one orbit. The full database of impact locations seems to be useful as an indicator of where Orion’s remains can be found.

Orion's Impact Area

In a recent post I showed that one event in the seismic catalog of the Moon seems to have recorded the impact of the Apollo 16 Lunar Module “Orion”. This event occurred late on May 29th, 1972, about five weeks after Orion was jettisoned. Then in my last post I described a way to “nudge” the initial conditions of a simulation in order to move the impact date/time towards the time of this event. Using this nudging technique, I have been able to generate several hundred simulations, all random variants of the nominal orbit of Orion, all of which impact the Moon within an hour of the target event at around 21:14 UTC. I have posted csv and Excel versions of the combined result files on GitHub. The files include the initial orbital state used for the simulations plus other initial state data, along with the impact location and time for each case.

We can’t have perfect knowledge about the initial orbital state of Orion. These simulations represent a set of initial conditions that vary randomly around my best guess at the nominal state, allowing us to get a reasonable picture of the possible outcomes for Orion given the uncertainties. What is exciting about the results is that the simulated impacts are concentrated in four “high terrain” areas of the Moon. These are the same four impact areas I found earlier with a smaller set of simulations. That’s good! The search area didn’t expand even though we have a larger database.

Figure 1: Impacts from the new database superimposed on a map of the Moon. There are over 350 simulated impacts, all striking the surface within an hour of the target event on May 29th, 1972.

Figure 1 shows the impacts superimposed on a map of the Moon. You can see that each impact cluster is in a place where the terrain is higher…mostly along the ridges surrounding craters. Again, this makes sense: as the orbit destabilizes, the spacecraft is on a flat trajectory at its low point, and it will strike the first piece of high ground it encounters. Overall the possible locations for Orion’s final impact seem pretty well constrained.

Could we tighten things up even more? In looking deeper at the data, it appears that we can. In the result files mentioned above, one extra parameter included for each parameter set is Orion’s initial inclination. Using this data, we can look for any correspondence between inclination and impact point, as plotted in Figure 2. Lo and behold, there is a pattern! The impact longitudes cluster into bands depending on the initial inclination. If we could determine the inclination more precisely, we could focus in on one or two of the clusters.

Figure 2: Orion's Impact Longitude versus Initial Inclination. All the simulations close to the nominal inclination value result in impacts near 104.3° East longitude. This leads to a very small area to search for Orion's impact crater.

As it happens, we can get a very good guess at Orion’s initial inclination, thanks to the Metric Camera database. Prior to casting off Orion, the Apollo 16 crew ran a camera pass, exposing a 70 mm film picture of the Moon’s surface every 10 seconds. Meanwhile another camera took simultaneous pictures of reference stars, so as to know exactly which way the mapping camera was pointing for each shot. This allowed NASA to determine the latitude and longitude of each picture with great precision, which works back to the latitude/longitude of the spacecraft. 

Inclination means how much the orbit is tilted away from the equator, so if we look at all the pictures and find the one that is farthest north or south of the Moon’s equator, that tells us the inclination. It turns out that during revolution 60, a few hours prior to when Orion was jettisoned, there was a mapping camera pass, and we can see from the image database that image AS16-M-2828 was the south-most picture in the run, taken from a point above 10.55 °S. Therefore, the orbit was tilted 10.55 degrees away from the Moon’s equator. Since the orbit was “retrograde”, or against the Moon’s rotation, we reference the inclination to 180°, so it is expressed as 180-10.55 = 169.45°.

Take a look at Figure 2 again. If we limit the inclination values from 169.4° to 169.5° All the impact longitudes are in a narrow band around 104.3°. Wow! That gives us a very small area to look for Orion. Figure 3 is a plot of the impacts from this narrow inclination range. They are clustered within +/- 0.1 degrees in both latitude and longitude. That translates to a square-ish area about 6 km on each side.

Figure 3: A plot of impact locations after applying the inclination constraint. This is an area roughly 6 km on a side. Based on all the evidence, this seems to be the most likely area where Orion struck the Moon in 1972.

To give a sense of scale, Figure 4 compares this impact area to a part of Pasadena, California that is similar in size. The California Institute of Technology is at the lower right corner and the Jet Propulsion Laboratory is at the upper left. The Rose Bowl stadium, along the left about 1/3 of the way from the bottom, gives a sense for the scale of the craters.

Figure 4. Comparison of the impact area to a section of Pasadena, California.

I'm really surprised at how far this analysis has come. When I started, I was hoping that perhaps one of those Mapping Camera pictures should show the impact area BEFORE impact, making it possible to compare with modern images, and perhaps identify any "new" crater. It turns out that isn't feasible. None of the pictures from the mission provide the needed coverage. Given the relatively small size of the area I have identified, perhaps an exhaustive search may turn up some craters or features of interest? 

I have been very impressed by the work of Dr. Phil Stooke, who has been able to identify Lunar Module impact locations for Apollo 12 and Apollo 15, among other notable finds. Perhaps, with the above analysis as a starting point, Dr. Stooke or others might be able to locate the final resting place of Orion someday. 

Impact Analysis

 

The simulation environment I am using, GMAT, doesn’t know anything about the Moon’s mountains or valleys. When it calculates the altitude of an orbit, that altitude is relative to the “mean radius” of the Moon, somewhat comparable to “sea level” on Earth. So far, in the simulations I have run for the Eagle and Snoopy, that hasn’t mattered, because the orbits of both objects remain high above the surface. But to estimate the location of a possible impact, as for the Apollo 16 subsatellite, we have to do a deeper analysis. In this post I’ll explain how that works. 

Let's start with the big picture. An orbit has become more eccentric…the high point of the orbit has moved higher, and the low point of the orbit has moved lower. On Earth, as the spacecraft began to skim the atmosphere, it would slow down, then burn up, and the heaviest bits might make it all the way to the surface. Since the Moon has no atmosphere, the spacecraft, at the low point of its orbit, can zip past the lunar surface at very low altitude, moving more than a mile per second, and if it misses the surface, even barely, it can continue around for another pass. 

Figure 1: The path of a spacecraft passing low over the Moon's surface

If the Moon were a smooth ball the impact might occur at the lowest approach. However, the Moon is not so smooth. In fact, it is quite rough, with jagged surface features thrown up by countless meteoroid impacts, undiminished by wind or rain. If a spacecraft comes streaking by and strikes the surface, that impact will likely be on a piece of high terrain, perhaps the side of a mountain or a crater wall. To work out the location, we’ll need a good elevation model of the Moon’s terrain. Fortunately, these are freely available, with resolution as high as 512 points per degree, which works out to one elevation point for every 100 feet or so.

We also need the simulator to give us a full “ground track” record, instead of just the lowest point of each orbit. The ground track is a list of latitude, longitude, and altitude points and typically a point is recorded for every 10-20 seconds of simulated time, as in the example shown below. Given that the spacecraft is traveling at about one mile per second, there is a lot of ground between each point. It’s not enough detail to locate the impact exactly, but it shows us the places where the spacecraft is close to the surface…places where we can zoom in for a closer look. As we go through this exercise, we will be zooming in on the points highlighted in green.

Figure 2: Ground track file excerpt. The terrain and "AGL" altitude data (in km) was added by post-processing the output from the simulator.

The first thing we need to do is to “post-process” the ground track file, looking up the height of the surface for each point in the file. For this method I am greatly indebted to a space enthusiast named Daniel Estevez, who ran simulations to try to estimate the impact location of a lunar satellite and posted his results here. I use a modified version of his method, wherein I run two passes on the ground track file.

Step one is to go through the ground track, one line at a time. From the latitude and longitude, we can look up the nearest terrain altitude point in the elevation model. Once we know the spacecraft altitude and the terrain height, we can calculate its “Above Ground Level” altitude. I write out a new copy of the ground track file with the extra terrain altitude and “AGL” data points added to each line, like the yellow values shown in the figure above. To limit the size of the new file I discard any point where the spacecraft is more than 5 km above the surface.

Here is a plot of a ground track file showing two low revolutions of a spacecraft over an area of the Moon. One thing to notice right away, even though this is covering 30 degrees of longitude, or a distance of about 900 km, the "zero" altitude point is flat, and the satellite trajectory curves upward, away from the Moon. This is just to make it easier to plot out the data. I promise the Moon is NOT flat, and the spacecraft is always curving towards the center of the Moon, as in Figure 1 above. The flattening of the Moon for this chart doesn't affect our ability to find the impact point. Another thing to keep in mind is that the vertical scale is greatly exaggerated. This chart is 900 km wide and just 8 km high.

Figure 3: A "flattened" plot of low passes of a spacecraft over the Moon. The area in the green box depicts the values highlighted in green from Figure 2.

Figure 3 allows us to see the areas where the spacecraft is coming close to the surface of the Moon. In particular, the points in the small green box highlight the closest approach visible at this resolution, and the closest point shows a separation of 449 meters above the ground. Given that these two data points are separated by a distance of over 20 km, we need to zoom in and take a closer look.

Figure 4: A "zoomed in" look at the region of the green box from Figure 3. We see that the spacecraft altitude is lower than the terrain altitude at 98.97°. Kaboom!

The figure above shows the zoomed in view. The two red dots are the points from the green box of Figure 3, the same data points highlighted in the ground track file in Figure 2.  What we have done is to make a straight line between these points, and break that line into 100 shorter segments, like the dotted blue line. (This process is called linear interpolation.) For each blue dot we can again look up the terrain altitude and compare it to the spacecraft altitude. Sure enough, in that intervening 20 km between the two red points there was a mountain, about 800 meters tall, and the spacecraft (moving from right to left in this example) strikes it near its top, at around 98.97°. 

How do we know there wasn't another mountain lurking somewhere further to the East? We don't! We have to check. In my code, posted here, I check any time I find a point that is within 3 km of the ground. (I also tried higher thresholds, but 3 km seems to be sufficient to catch all the lurking mountains in my tests so far.)

This is how I have used GMAT to estimate the impact location of the Apollo 16 Particles and Fields Subsatellite, the notorious (in some circles) PFS-2. Now that I have this tool working, I am interested to use it to investigate another Apollo impact. Yes, there is another spacecraft from the Apollo era whose final resting place is unknown...the ascent stage of the Apollo 16 Lunar Module "Orion". As I write these words the 50th anniversary of that mission is fast approaching. Stand by for further updates.

A Reality Check

 What about that Apollo 16 subsatellite?

In this blog I have shown that two Apollo spacecraft were left in orbits that are stable over decades. That’s really surprising and unexpected. Some people have asked if I can simulate an object that is known to have decayed out of orbit, as a reality check, to show that these simulations aren’t out of whack. That’s what we’ll do in this post.

One very notable case is the Apollo 16 Particles and Fields Subsatellite, otherwise known as PFS-2, which decayed out of lunar orbit in 1972 after only 5 weeks in orbit. Weighing just 36 kg, it was jettisoned from the Apollo 16 Service Module not long before the crew left lunar orbit to return to Earth. Originally it was planned to raise the orbit of Apollo 16, so that PFS-2 would remain in orbit for a year. Due to problems during the mission, that orbit change was skipped, and the expected orbital lifetime of PFS-2 was cut down to a few months. PFS-2 was equipped with a transmitter so that it could be tracked, and its data could be sent back to Earth. Only 34 days after it was jettisoned, the transmissions ceased, and PFS-2 impacted the Moon. 

Let’s run a simulation of PFS-2 and see what happens. As with previous simulations we can get the initial conditions from the Mission Report. The Figure 1 shows the data from the report. I believe the report is showing the state of the Command-Service Module (CSM) rather than the PFS-2, but it should be close enough to see if we are in the right ballpark. After converting the parameters to metric and getting them into the right coordinate frame, I get a GMAT script like this one, posted on GitHub.

Figure 1: Showing the initial conditions of PFS-2 from the Mission Report.

For starters, we’ll just record the low point in each revolution, as we have done previously. Figure 2 shows how it looks over time. We see the minimum altitude dropping for several weeks, and then there is a reversal and it starts to rise up again around the middle of May. About a week later the orbit starts to become more eccentric, and the perilune altitude begins dropping again. Sure enough, just 5 weeks after jettison, at the end of May 1972, the low point of the orbit is below the average radius of the Moon...zero altitude...and that is a sure sign that impact has occurred. (The simulator doesn’t check for impact while it is running…it will happily simulate an object that is actually beneath the surface, so we’ll have to look in greater detail to see exactly when and where the impact occurs. I’ll explain how to do that in a future blog post.)

Figure 2: Simulated perilune altitude.

A more detailed analysis of the simulation results gives the location and time of impact, and it comes out as below. Tracking data from the satellite ended shortly after 10:31 PM on May 29th, with an estimated impact at 111° East longitude, and 10° North latitude. This simulation puts the impact about 14 hours later, and about 13 degrees further west. That's not bad! 

Figure 3: Impact times and locations reported by NASA and estimated by simulation

There is another source of information on the PFS-2 initial orbit, at this page. It describes the orbit in a different way, and the parameters don’t completely agree with those in the Mission Report. If we run again with those initial conditions, we get the results labelled “Nominal 2”. This time we get closer to the 1972 estimated impact location and time…impacting about three hours earlier and about 4° more to the west, with the latitude agreeing almost exactly.

In my view, the basic answer is “yes”, these simulations do compare well against reality. We are able to predict the impact of PFS-2 within a few hours of the actual time, and within a few degrees of the estimated location. Considering the uncertainty of the initial conditions, with two different NASA sources that don’t agree, errors of a few hours either way don’t seem too surprising. Having gone through this exercise, I have even greater confidence in the results obtained for Eagle and Snoopy.

By the way, if you are looking for a lunar sleuthing challenge, the actual impact crater of PFS-2 has never been located. This web page states that the original raw PFS-2 tracking data has been preserved, and if you were to obtain that data and fit a simulation to it, I suspect you would be able to map out a very small area where the PFS-2 impact occurred on the surface of the Moon almost 50 years ago. You might be the person to identify the final resting place of the infamous short-lived Apollo subsatellite. Good luck and happy hunting!