Custom Visuals, LLC
Automated Processing | Application Development | Database Integration

NASA Program Language Requirements

I made a comment recently about arbitrary decisions and related expenses to a colleague that brought up a couple old stories. In 1996, while working for Hughes Aircraft in Santa Barbara, CA, I began work on a new satellite data project. The MODIS satellite sensor was being built by Hughes and I was tasked with building an algorithm test bed for it. The group I was part of had spent several years working with the IDL programming language and had sent me off to an IDL class at Research Systems’ (the IDL developers, now a division of ITT) offices in Colorado. I later went on to host and maintain the IDL FAQ, as well as teach IDL classes for Research Systems. Basically, I was a very experienced IDL developer at this point. Our group had also developed a substantial library of custom functions in IDL and used them regularly.

A week or two after beginning IDL development for MODIS, my boss dropped by and had a talk with me. As specified in the program specs, we had to deliver all new code in either C or PV-Wave, IDL would not be accepted. We pushed back for some clarification on that, and it was reiterated that IDL could not be used because PV-Wave was specified by NASA. This wasn’t a huge issue since PV-Wave was based on a copy of the IDL source code sold from Research Systems to Visual Numerics. This meant the core language and functions had a very large overlap and the companies were direct competitors in many of the same fields. In the years after the source code had been sold, both companies had developed it in parallel, but different ways. The main difference between the two were the GUI elements, which had diverged quite a bit from each other.

As it happens, a large portion of what I was working on required a GUI for the engineers to be able to quickly load, apply and view the results of varying algorithms, so this had a pretty big effect on me. Essentially, half of what I was very familiar with in IDL would have to be written differently in PV-Wave. Also, functions that had some options in IDL had different options in PV-Wave as both companies extended the language in different ways. So, development switched to PV-Wave, and eventually I got my footing in the PV-Wave manner of GUI design. I stopped grumbling about the differences and made several nice applications for the engineers to work with the MODIS data.

After about 3 months of development, we were demoing our applications for NASA on their systems when we hit a snag. After loading our code and data and bringing up the GUI to start processing some of the data, a dialog box came up indicating we were not licensed to load the data. After bringing in a couple of the technical staff, it was determined that the NASA team we were working with had not purchased PV-Wave for the project, they had just requested a demo license and had never run it beyond watching the demo screens. The demo had been enough to dictate that PV-Wave would be written into the contract and IDL would be excluded. While not exactly an arbitrary decision, it certainly wasn’t a decision based on a detailed analysis. It cost some additional time in development for me to come up to speed with the PV-Wave way of GUI design and the occasional issue of having to rewrite functions from our IDL library to work within the PV-Wave library.

The project continued on in PV-Wave of course, and was eventually completed, delivered and accepted along with all of the other software, hardware, manuals, etc. that you might imagine goes along with providing a sensor that will spend years operating in a satellite. Some time later, I also created the PV-Wave FAQ to go along with the IDL FAQ I was maintaining. As mentioned above, this took place in 1996 and MODIS is still operational at this time (July, 2009).