New analysis software for Viking Lander meteorological data

We have developed a set of tools that enable us to process Viking Lander meteorological data beyond what has been previously publicly available. Besides providing data for new periods of time, the existing data periods have been augmented by enhancing the data resolution significantly. This was accomplished by first transferring the original Prime computer version of the data analysis software to a standard Linux platform, and then by modifying the software to be able to process the data despite irregularities in the original raw data and reverse engineering various parameter files. In addition to this, the processing pipeline has been streamlined, making processing the data faster and easier. As a case example of new data, freshly processed Viking Lander 1 and 2 temperature records are described and briefly analyzed in ways that have not been previously possible due to the lack of data.


Introduction
The Viking Mission launched in 1975 was the first successful lander mission to Mars, arriving on the Martian orbit in the summertime 1976.The Mission had a versatile set of scientific objectives.Primarily, the Viking Mission was aiming at the investigations of the current or past existence of life on Mars, but other experiments were also designed, including meteorological and seismological measurements and experiments on the composition of the atmosphere (Williams, 2011;Chamberlain et al., 1976;Soffen, 1977).
The mission consisted of two separate unmanned spacecraft, Viking 1 and 2. Each spacecraft further consisted of an orbiter and a lander.The Viking landers 1 and 2 (VL1 and VL2) were each expected to be operational for 90 Mars solar days (sols), later changed to 60 sols for VL2 (Soffen, 1977;Snyder, 1977).The Viking Mission was a tremendous success in all aspects of planetary science.Especially important from the atmospheric sciences point of view was the provision of a record of atmospheric observations on two surface sites during a period of several Martian years.
After Viking there was a hiatus of about two decades before the Martian in situ exploration was successfully resumed.The importance of the Viking Mission is underlined by the fact that all the Martian exploration missions after Viking are referring to the Viking data records.This is especially the case for all the landed Mars missions with atmospheric observations, e.g.Mars Pathfinder, Phoenix, Mars Science Laboratory (Linkin et al., 1998;Harri et al., 1998;Golombek et al., 1999;Savijärvi et al., 2004Savijärvi et al., , 2005;;Shotwell, 2005;Taylor et al., 2008Taylor et al., , 2010)).
The Viking landers operated significantly longer than expected: VL1 was operational for 2245 sols and VL2 was operational for 1281 sols.After about sol 1000 of the VL1 mission the responsibility of storing the data was transferred from Jet Propulsion Laboratory (JPL) to James E. Tillman and his University of Washington Viking Computer Facility (UW VCF) staff, who made it possible for the Viking program to provide yet unmatched amount of long-term meteorological data (Tillman et al., 1988).The earliest possible year for any lander to surpass the extent of the Viking direct meteorological data is 2018, when Mars Science Laboratory may have been on Mars for over 2245 sols.It is worth noting that Mars Exploration Rover Opportunity has been operational on the surface of Mars for over 2245 sols, and that it carries a Mini-TES instrument capable of making some indirect measurements of meteorology (Smith et al., 2006).
Published by Copernicus Publications on behalf of the European Geosciences Union.

O. Kemppinen et al.: New analysis software for Viking Lander meteorological data
Each Viking Lander had instruments for several fields of science, such as geology, imaging and meteorology.The meteorology instruments included a pressure sensor, a temperature sensor and wind sensors for velocity and direction measurements.The complete pressure data of both landers has been published in the Planetary Data System (PDS), but the temperature and wind data found in the PDS is severely incomplete.For VL1, the published temperature and wind data covers the first 350 sols of the 2245-sol mission.VL2 mission is covered completely (1281 sols).However, for every sol only 25 temperature and wind data point averages are provided, whereas the full data amount is between 150 and 2000 measurements per sol.Therefore, in addition to the large missing portions of the VL1 data, the resolution of the published temperature and wind data is severely limited.
When the support at the UW for the original Viking team ended in 2004, Finnish Meteorological Institute (FMI) as a longstanding cooperation partner in Mars meteorological sciences was contacted with the request to continue the work on the data and to upgrade the original data analysis software from FORTRAN IV format of the Prime computer system to one that works in a standard Linux environment.At FMI, the original FORTRAN IV code was adapted to the Intel Fortran 90 compiler, the C-routine package was completely rewritten for the Linux environment and the Command Procedure Language (CPL) process control scripts were translated into Perl scripts.The original software is briefly described in Sect. 2 and the current processing pipeline is described in Sect.3.
In addition to the platform changes, the software has been significantly modified to be able to analyze data that has been unavailable until now.The first results are summarized in Sect. 4. This is the first article describing the preliminary new data produced with the new version of the software.The main purpose is to give an overview of the data processing software and describe the current version of the data.A more complete overview and in-depth analysis of the data will appear in subsequent articles.
The data discussed in this article consists only of the temperature measurements.The atmospheric pressure data were engineering measurements, serving both entry and landing needs, so they were processed separately from meteorology.In addition, the wind data validity is still being verified.For VL1, the main issue is that the software changes made to account for a malfunction of the quadrant sensor heater and a failure of one wind sensor cause singularities for wind speed.For VL2, the processing package produces non-outlier noon wind velocities of up to 80 m s −1 near sol 700, which forces us to consider that there might be a problem with processing even in the intact wind instrument data.

The original Prime-based analysis software (OPS)
Except for atmospheric pressure, the original software was completed in 1975 and was written for Universal Automatic Computer (UNIVAC) 1108 computer system by Martin Marietta corporation, for the purpose of analyzing Viking lander meteorological data (Buehler, 1974b,a).In 1976 it was ported to FORTRAN IV to be used with the UW Prime 400 computer.The development continued at VCF, where it was used for all routine data analysis of the extended mission data products and for special data analysis in connection with the preparation of scientific publications (Tillman et al., 1988).
Since the Prime 400 version, the software has had four core software packages, processed linearly in order.Most of these packages were written in FORTRAN IV, but a bit manipulation package was written in C and adapted to the operating system environment.The core software packages were controlled by Command Procedure Language process control scripts, feeding configuration parameters from various databases together with the original or pre-processed data sets to the FORTRAN IV software.Many of these configuration parameters were based on mission operation information logged manually during the mission.When the responsibility for the data processing was transferred to the UW, the new crew started to use calibration information collected during the first months of instrument operation on the Martian surface and during additional wind tunnel experiments on the ground.These values deviated somewhat from the parameters used by the JPL system (Tillman et al., 1988).

Updated Linux-based Viking analysis toolbox (ULT)
ULT is a new tool for Viking lander meteorological data analysis.It is in essence an update of the OPS that has been modified to cope with several irregularities in the raw data that cause the original version to crash.ULT runs in a local FMI Linux cluster, but works in any Linux environment, such as a personal computer or a cloud.Furthermore, the software was streamlined in a way that processing the data for the whole mission does not require non-trivial human interaction.In addition to modifying the original software pieces to run automatically, the streamlining was accomplished by creating a generator script for essential <names> parameter files, described below in more detail.In the Linux version, we have preserved the software and data file naming conventions of the Prime version of the software.
In the text below, software packages and their subcomponents are written in capital letters, for example SANMET.File type names are enclosed in symbols < and >, for example <MFILE>, to make it explicit which terms correspond to software packages and which terms correspond to data files.
The original raw data stream from both of the spacecraft was stored in Intermediate Data Record tapes.These tapes  (Tillman et al., 1988).The software information flow is summarized in Fig. 1.Below, each part of the program is described in more detail.The naming convention of the sub-parts of the programs are loosely based on the actual subroutines.As the objective is to describe the general structure of the programs, in tables below some of the helper routines are omitted or merged to the main subparts for the sake of clarity.The program runs the subroutines linearly in the order shown in the tables.
First, DECSET extracts complete frames from the unformatted bit stream contained in MDR files by searching for frame synchronization patterns.Next, it discards the frames which are not meteorological or desired, and finally it outputs the meteorological frames in a format understood by the next program, Pre-Front End Processor (PREFEP).This format is called <FMT 7 metout>.DECSET general structure and the individual subparts of the program are briefly described in Table 1.
PREFEP reads meteorology frames from <FMT 7 metout> files and checks frames to see if they fit in an appropriate module and record times that are provided either manually by the user or, as done in the current version, read from a file called <LSEQ>, Lander Sequence of Events.Additionally, PREFEP transforms the time format from the bare on-board counter time to one utilizing information about the mission epoch in addition to the counter, sorts the good frames according to Lander Local Time (LLT), and outputs the frames in a Front End Processor (FEP) compatible form.This form is called <MFILE>.The time transformation becomes necessary as the original time counter covers only the three month mission time planned in the beginning, after which it resets to zero and starts over.The epoch is an additional counter, measuring how many times the on-board counter has overflown, i.e. reset to zero.Each "time" information therefore has to be corrected with the related epoch to generate an unambiguous linear time scale across the whole mission.PREFEP general structure and the individual subparts of the program are briefly described in Table 2.
After or concurrently to PREFEP a <names> generator script is run.This script generates a parameter file called <names> for each sol.Each <names> contains information about various processing variables, data timing, and instrument voltage limits for one sol.The original <names> were created manually and are now unavailable.The variables used are partially based on the few original <names> we have, and partially reverse engineered from the program input format requirements.FEP reads in an <MFILE> and a <names> for each sol, converts the measurement binary data to instrument voltage values, checks if any of the voltage values exceed the set limits and replaces the voltage value with a default value if needed.The voltage data is written in a format called <METFL3>.FEP general structure and the individual subparts of the program are briefly described in Table 3.
All the actual analysis is done by Meteorology Analysis Program (SANMET).SANMET reads in a <METFL3> and converts the voltage values of the instruments to engineering variables, which are then used to calculate the scientific variables.The values are written to one-sol files, from which the data is extracted to a final table format for easy usage.SANMET general structure and the individual subparts of the program are briefly described in Table 4.A key subroutine WNDTMP is further described in Table 5.The details of operation can be found in SANMET Program Description Document (Buehler, 1974a) or SANMET Users Guide (Buehler, 1974b).A sequence number system is used in all the processing phases to preclude the outputs of different runs from overwriting each other.The sequence number system makes it possible to, for example, preserve <MFILE>'s of several PREFEP runs in case the user wants to try different FEP configurations for different PREFEP configurations.As a side effect, it also enables the user to have to run only a part of the processing pipeline in case a software or configuration change is made.As an example, if the user wants to change SANMET run parameters, DECSET, PREFEP, <names> generator script and FEP do not have to be run again, because <METFL3> files already exist.

Illustration of the new temperature data
As mentioned in Sect. 1, only the temperature data is discussed here in any detail.Even though the quality control process is still ongoing, we feel confident that the temperature data is fairly accurate.Most of the gaps in the data are caused by a couple of missing raw data tapes.Those tapes have been lost for over 25 yr, and therefore recovering them seems unlikely.Below follows a description of the data, which is available at present.Table 6 shows the amount of temperature and wind data produced with ULT and compares it to the amount of data previously published in Planetary Data System (PDS).Although the ULT-produced data contains gaps, it covers a significantly greater portion of VL1 mission's sols than the PDS data, 70 % of the sols compared to 15 %.Judging from operational logs and the gaps in PDS pressure data, it seems likely that all the leftover gaps in the ULT data are caused by either operational causes, such as gaps in Deep Space Network coverage or missing raw data tapes, and as such can be assumed to be unrecoverable.However, as PDS has more data for VL2 than ULT data, it is possible that data for some of the gaps still exist in some kind of an alternative or backup data format.In case the reader has any further knowledge of these missing raw data tapes, we kindly ask him or her to contact the authors as soon as possible.
In addition to filling some of the previously void sections of the mission, the amount of data points per sol is much greater in the data produced by ULT.VL1 has on average 36.8times and VL2 has 56.8 times the data points compared to PDS data.Therefore, whereas the PDS data temporal resolution is one hour, ULT data has mean temporal resolution of 96 s for VL1 and 63 s for VL2.The best resolution found for both landers is two seconds, but that was only available for short periods of time.For almost the whole first half of both lander missions (sols 1-847 for VL1, sols 1-695 for VL2), the daytime data resolution is 31 s, and nighttime data resolution is 63 s.After that the data resolution is approximately 9.1 min for VL1 and 11.6 min for VL2.
For coverage calculations and some figures, the parsed data are binned to 25 evenly distributed bins of equal width (numbered from 0 to 24), and as long as a bin contains at least one data point, it is deemed non-empty.Complete coverage is here defined as some data existing for every 1/25 th of the sol.
For the VL1 ULT, of the 1561 sols that contain some data, 1282 are covered completely.Sols, which have at least one but less than 25 non-empty bins, are called partially covered sols.Partially covered sols have on average 67.6 % (16.9 25 ths) of the sol covered.
For the VL2 ULT of the 826 sols that contain some data, 570 are covered completely.Partially covered sols have on average 68.0 % (17.0 25 ths) of the sol covered.Freshly produced data by ULT can be illustrated by a few temperature data cases.In Fig. 2 the VL1 mean temperature of (12:00, 13:00 LLT -Lander Local Time) of each sol is shown for sols 1-850 and for both the PDS and ULT data, depicting one full Martian yearly temperature cycle.In addition, equinoxes and solstices are shown with vertical lines.The figure illustrates the fact that the data produced with ULT matches the PDS data fairly well where the latter is available.For some sols there is a difference of several Kelvins, but generally the trends are very similar.
In the following figures, it is good to note that there were several global dust storms during the VL mission and that some of the irregularities in the plots can be explained by them (Tillman et al., 1994).A quantitative description of dust storm effects on the various meteorological quantities will be discussed in an upcoming publication.
The general behavior of both the daily mean and the midday temperature during a Martian year at the VL1 site is as follows.First, the temperature rises from sol 0 until approximately sol 100, when the temperature is at its yearly noon maximum of approximately 245 K.After that, the temperature starts to decrease for 230 sols.The decrease is not linear, but instead consists of two periods of fast decrease and one period of slow decrease.The decrease ends in the yearly minimum temperature of approximately 200 K.
After the minimum, the temperature starts to rise, first rapidly for 70 sols and then slower for 120 sols.Then, at about 550 sol, the temperature is at a local maximum.The maximum ends when the temperature decreases approximately 3 K, after which it starts to rise again.The rise is slow for 100 sols, but becomes faster after that.Finally, the yearly maximum is reached on about sol 800.
Figure 3 shows the VL1 temperature plots of different times of a sol.The noon temperature peaks close to the fall equinox, after which it starts to decrease rapidly.The minimum temperature is achieved approximately 20 sols after the winter solstice.After that, the temperature starts to rise again in the beginning approximately at the same rate as it decreased during late fall and winter.The rising of the temperature slows down after the vernal equinox and comes to almost a full stop shortly before summer solstice.During the first year, the noon temperature actually seems to decrease a couple of degrees near summer solstice.After the solstice, the temperature starts to rise again until the maximum at fall equinox.
The midnight temperature has a low variability compared to the noon temperature.The midnight minimum temperature is approximately 20 • lower than the midnight maximum temperature.In contrast, the difference between the maximum and the minimum noon temperature is approximately 50 • .The sol mean is, by visual inspection, approximately the mean of midnight and noon temperatures.The yearly minima and the maxima of all the temperature curves coincide fairly accurately.
VL2 plots are shown in Figs. 4 and 5.The behavior is similar in the sense that there are clear diurnal and seasonal variations, and that diurnal variation is much greater during summer than during winter.VL2 plot is significantly more symmetrical and smooth.The shoulder during early winter is almost invisible, and the dip around the summer solstice is much smaller.Moreover, the seasonal variation in midnight temperature is much greater.
In the following text the time is given in LLT, which is the local solar time at the location of the lander.LLT runs from 00:00:00 to 24:39:35 LLT, where hours, minutes and seconds are equal to those on Earth, and 00:00:00 LLT is the midnight.In addition, for easier comparison to figures, the time is given in a fraction format in parentheses following the LLT.As an example of the usage, the sol begins at 00:00 LLT (.0) and noon occurs at 12:20 LLT (.5).For simplicity, the LLT is rounded to the nearest minute.
Figure 6 shows a temperature plot of sol 645.During the night, the temperature decreases steadily until 04:56 LLT O. Kemppinen et al.: New analysis software for Viking Lander meteorological data i.e. 8 h, on a single 2.66 GHz core.The software does not at present time implement any multi-thread parallelization, but due to the discrete and independent nature of sol-specific analysis it would be suited to parallelization very well.If a faster performance is desired that is an obvious step to perform, in addition to running the software on a faster core.In theory, with a thousand cores, each of them processing data of a single sol, the processing time should be very fast, no more than a few minutes.
The memory consumption of ULT is at most a few hundred MB during processing.With multiple threads the memory consumption would likely increase almost linearly as a function of the number of threads.A complete set of processed data, all phases combined, takes approximately 2.5 GB of hard disk space.The raw data takes a few hundred MB of hard disk space.The source code of ULT takes a few MB of hard disk space.
The general structure of ULT is the same as in the original analysis software and consists of four core packages that are run linearly.In addition, we developed a new algorithm called <names> generator to enable the analysis of the previously unprocessed VL data.
The first package, DECSET, extracts meteorological data frames from the raw bit stream.The second package, PREFEP, matches the data frames to known measurement times.The <names> generator script generates runparameter files based on PREFEP output.The third core package, FEP, performs bit-level verification for the PREFEP output and additionally replaces data points that are flagged as outliers by pre-determined backup values.The fourth and final package, SANMET, calculates the atmospheric temperature and the wind vector.
ULT and the data produced by it are currently undergoing a validation process.Barring any discoveries of serious problems, we plan to release the data during years 2013-2014 in the PDS.ULT itself, as well as the documentation, will be available via a request.
For temperature and wind data, ULT has 4.7 times as many VL1 data sols and 0.89 times as many VL2 data sols.The amount of data points per data sol compared to Planetary Data System (PDS) data are 36.8times as much for VL1 and 56.8 times as much for VL2.Judging from operational logs and PDS pressure data, it seems that all the remaining gaps are caused by missing Magnetic Data Record (MDR) tapes or operational causes, and therefore unrecoverable.However, as PDS data has more data sols than ULT data, it is possible that some of the gaps can still be recovered with some kind of an alternative or backup source.

Fig. 1 .
Fig. 1.Flow chart of the analysis package.The explanations of the abbreviations are explained in Sect.3.

Fig. 3 .
Fig. 3. ULT VL1 noon, midnight and sol mean temperature data of the whole mission.

Table 3 .
Bit error and outlier detection (FEP).voltagevaluesfit into the limits set in a LSEQ file, and if not, replaces them with defaults found in the same fileREJCTSearches for outliers by checking each value against the mean and standard deviation of the rest of the data, and in case a discrepancy is found, replaces the value by a running mean OUTPUT Outputs the data

Table 4 .
Supporting scientific variable calculation (SANMET general).systemfromhorizontal to that of the Viking Lander CMPFCT Calculates the compressibility factor of the atmosphere based on the pressure and information of its constituents TABLUK Converts data frame Julian times to L s and Lander Local Time ANGLS Calculates sun elevation and its azimuth at the Viking Lander location based on the timing information DATA6Converts voltage values to engineering units MOMNT Calculates the mean, standards deviation and skewness of the data array WNDTMP Calculates the real scientific temperature and wind values from the raw ones WNDTMP is explained in a more detail in Table5

Table 6 .
Quantitative comparison of PDS and freshly processed (ULT) data.