I can’t believe it’s been two years since the last conjunction and the start of PSP! A lot has changed since we started out with those first images. Check out some of these early blog entries to see how far we’ve come:

• Preparing for Transition Phase imaging and beyond
  

• First look at our initial images from mapping orbit.
• Opportunity! – use of one of our early images to help plan a rover drive.

The last image we’re planning on taking during PSP will be PSP_010901_2265: a new cluster of craters that we think formed very recently. For comparison, to the right is another cluster of recent craters that we imaged last winter (PSP_007431_1870). This should be a great image to finish off this phase of the mission!

Don’t worry, though, the end of PSP is far from the end of our mission. MRO has been approved to continue science operations for another two years. That time period was originally called the “relay phase” of the mission, when it was thought MRO would mainly be relaying data for Phoenix and MSL. However, now Phoenix is basically done, and MSL won’t be there for a while, so it’s not really a “relay” phase. Instead we’re calling it “ESP” for Extended Science Phase. Although we are making plans to simplify and streamline some of our operations, we expect to be doing things much the same way for the next two years – and hopefully for a long time after that!

A few days ago I realized that after more than a year, I was still in the manual stage of monitoring data quality and not making good use of existing tools to help streamline the process. All that cutting and pasting was beginning to get ridiculous, even more so during a period of high data rates and an increasing number of observations.

When we receive a product with gaps, our automated processing pipelines usually process it just fine. Sometimes, however, there are pipeline failures. I keep a list of these failures and the actions I have taken to try to correct the problem. This generally means I have to manually processing the file or repairing its metadata header. Once the channel is repaired and/or recovered, then I can feed it back into the remaining processing pipelines.

These gapped products include “_G” in their file name. In a spectacular “Duh!” moment, I realized that rather than hunting in my browser through a list of observations that might have gapped product names, and then copying and pasting any I find into Excel, I could instead just perform a command line search in Terminal for all raw data products with “_G” in their file name.

     % ls -1 */*_G*.DAT

Why didn’t I do this over a year ago!? I am embarrassed to say I have no idea.

This only provides a list of products with gaps. Missing channel products usually arrive as gapped channel products 48 hours later (due to the nature of the automated processes that handle new MRO data at JPL.) In my spreadsheet, I scan through the missing channels and determine if a gapped file has in fact arrived. If it has been longer than 48 hours I consider the data lost for good and I “force” whatever observation data we have received through the pipelines. Of course, sometimes lost data is found or reprocessed at JPL long after the 48 hours has expired, and very rarely these new data will arrive. This requires reprocessing of the entire observation so that this newly found data can be added in.

A long time ago, our database specialist wrote a Perl script to create a daily list of missing and partial observations. For whatever reason, I stopped using this tool and then promptly forgot about it. Instead I started looking through the list of observations in my browser, clicking on those that were not complete, and manually figuring out what channels were missing. Making use of this missing EDR’s tool is so much easier and faster. Again, “Duh!”

The output from these quick searches for gapped and missing products requires a little bit of tweaking to make it look nice in Excel, but then a quick sort merges the two list into observation ID order. In no time at all, I have my list of observation products to follow up on for the day. My copying, pasting, and mouse clicking madness has been vastly reduced.

Every day I see the very worst data, generally caused by data transmission problems, but these data make up only a small percentage of all HiRISE data. To try to quantify this, I counted up the number of channels I have reported with problems (they have gaps, were missing, were somehow corrupted, etc.) and then divided this number by the total number of raw data files we have received (these are transformed into EDRs after being downloaded to Tucson.) As of this morning, I have listed 5392 channels with problems, and we have received 160,858 raw channel files. This is roughly 3% of our data, although most of these have some useful data in them. Even an observation with gaps or missing a channel or two is of potential use to a scientist. If too much data has been lost, then our targeting specialists might command HiRISE to try again in a later orbit.

Over time, we have developed many procedures for dealing with all sorts of problems. Now that I have sped up my daily data quality monitoring, I will have more time to improve these procedures, partially automate as much as I can, and provide suggestions to the software developers about tools that would make my job ever more efficient.

Note: My calculation of problematic data above is not rigorous and only a rough estimate. One flaw: I am counting missing channels in the numerator but not in the denominator.

Audrie, Tahirih and I did not previously appear in pictures on HiBlog because during transition imaging we were busy working in our offices and Tuvas for some reason did not visit us. We feel so left out (joking)! The three of us make up HiRISE Downlink Operations, which includes downloading new images, processing them, and image validation (the Student Validators also participate in this task). Audrie also works on instrument monitoring and safety. Tahirih also does most of the geometry processing. I also eat cheetos and chocolate cake. When Kite is not busy with HiRISE Uplink tasks – which is generally NEVER – she is blasting her way out of impossible situations that often involve walking carpets.

A couple of weeks a go, we started the planning process by defining scientifically interesting areas on Mars to image. At this point, we didn’t know exactly where the MRO spacecraft would be in its orbit around Mars when the imaging sequence would begin (two weeks later). Consequently, we chose large regions of interest, rather than pinpointing the exact locations of each image that we wanted to acquire. Once MRO’s orbit pattern during the imaging sequence was predicted, we then carefully decided where within each region of interest HiRISE should acquire image. With this preliminary plan in hand, we then discussed our imaging desires with the teams for the other MRO science instruments, such as CTX (the context imager) and CRISM (the multispectral imager).

After a week of iterations and teleconferences, we had a working schedule of observations that incorporated the imaging desires of all the MRO science instruments. We then undertook the process of carefully designing each scheduled HiRISE observation (image). Planning a HiRISE image involves setting the proper camera parameters so that we take a good image. We need to set parameters such as exposure duration, the aerial extent of the image, the image resolution and data compression. Each parameter needs to be carefully weighed against factors such as the brightness of the surface of Mars, the clarity of the Martian atmosphere, the scientific objective of the image and the amount of data storage space available on the spacecraft.

After an intense week of designing our HiRISE observations, we sent these camera commands to JPL. At JPL, the commands were tested on a computer simulator (the OTB or ‘Orbiter Test Bed’). The purpose of this test was to ensure that each command would execute flawlessly on the spacecraft (and they did). These commands were transmitted to MRO earlier this morning (Thursday 9/28/06). Mars is currently about 309 million kilometers (about 192 million miles) from the Earth. At this distance, it took about 22 minutes for our commands to travel from Earth to Mars. These commands will automatically run on the spacecraft tomorrow and begin returning fantastic images of Mars. Tomorrow should be an exciting day!