-- RobertIacovazzi - 09 Apr 2009

Inter-Calibration of Low-Earth-Orbit Satellite Instruments Using the SNO Method

LEO-LEO SNO Intercal Process: 1a

Process Name: Selecting Orbits

Document History:

Date (yr-mon-day)	Responsible Official and Organization	Nature of Change or Revision
2008-12-18	Bob Iacovazzi, Jr. / NOAA	Original Document

1a.1 Scope

This document outlines the process used to 1) determine the time and location of simultaneous nadir overpass (SNO) events, and to 2) acquire relevant raw data granules needed for the SNO analysis.

Add

1a.2 Relevance to ATBD

Acquisition of raw satellite data is obviously a critical first step in an SNO analysis. To facilitate the acquisition of data for the purpose of inter-comparison of low-earth-orbit (LEO) satellite instruments, prediction of the time and location of SNO events is also important.

1a.3 Method Background

The Simplified General Perturbations Satellite Orbit Model 4 (SGP4) is utilized to find SNO events. The SGP4 is a NASA/NORAD algorithm for calculating the orbital locations of near-earth satellites (see SGP4 Introduction). The code algorithm was originally developed by T. S. Kelso, and was adapted to C by Neoklis Kyriazis in April 2001. More current versions of the code written in C++/C#, as well in Turbo Pascal, can be found on the Celestrak web site ( http://www.celestrak.com/), which is maintained by T. S. Kelso.

Actual data acquisition is performed using automated software that reads the most recent list of predicted SNO events computed by the SGP4 model, and adds them to a historical short-list of SNO events for which raw data have not been found. Daily, the software searches near-real time satellite databases for the orbits that are relevant to the SNO events listed in the historical short list. Once the raw data sets are found for a given SNO event, a SNO data subset is created (next step) and the event is removed from the historical short list and added to the SNO master list. If the data need to be stored locally, the software is also capable of performing data transfer to protected local directories.

1a.4 Current Implementation

At NOAA, we have created a C-driver program for the C-version SGP4 to find the SNOs between two satellites given a set of orbital intersection criteria. The SNOs can be predicted beyond a current time using the latest two line elements (TLEs) for each satellite pair, or in the past using several matched archived TLEs for each satellite. This driver was debugged and expanded from a version created by Changyong Cao. The SGP4 is scheduled to make a 21-day prediction of SNO events once per week, based on the latest TLEs. The SGP4 software also is run in an automated fashion on local LINUX-based computers using the cron facility.

The orbit acquisition software has been written in Interactive Data Language (IDL) and runs daily on local LINUX machines using the cron facility.

1a.4.1 Software General Attributes

1a.4.1.1 Authors

SGP4 SOFTWARE

Date: 2006-02-15

SGP4 Driver (main.c) Update Programmers: Bob Iacovazzi, Jr. and Changyong Cao, NOAA/NESDIS/STAR, Bob.Iacovazzi@noaa.gov

SGP4 Programmer: Neoklis Kyriazis (April 2001), T. S. Kelso (Original Pascal Program)

Coding Language: C

DATA ACQUISITION SOFTWARE

Date: 2005-10-03

Programmer: Unless otherwise noted, Bob Iacovazzi, Jr., NOAA/NESDIS/STAR, Bob.Iacovazzi@noaa.gov

Coding Language: IDL

1a.4.1.2 Modules

SGP4 SOFTWARE

distance.c - Find the double precision distance between two point on the globe.

sgp4sdp4.c - The source-code of the ported SGP4 and SDP4 routines and some extra functions for testing and setting flow control flags.

sgp_in.c - Functions for reading a TLE set from a file and verifying, converting and pre-processing the Keplerian element set.

sgp_math.c - Various mathematical functions used by other routines.

sgp_obs.c - Functions for calculating the geodetic position of the observer and converting the ECI position and velocity of a satellite to observer-centered azimuth, elevation, range and range rate. Also calculating the observer-centered position of the sun.

sgp_time.c - Functions needed to calculate and convert time in various formats, e.g. Julian, calender etc.

solar.c - Functions for calculating the position of the sun.

main.c - A basic main() function to demonstrate the use of the sgp4/sdp4 library to read a TLE set and calculate and print satellite predictions.

sgp4sdp4.h - A header file that should be #include'd in all source files using this library.

Makefile - A simple makefile for building the 'ephem' binary.

DATA ACQUISITION SOFTWARE

SNO Acquire Dataset Software Architecture Flowchart

mjd2date.pro - Converts MJD to year, month, and day. (Written by William Thompson, GSFC, 20 September 1993)

int2utc.pro - Converts CDS internal time to calendar format. (Written by William Thompson, GSFC, 20 September 1993)

utc2str.pro - This procedure takes the UTC time in "internal" or "external" format, and converts it to a calendar string. (William Thompson, GSFC, 20 September 1993)

tai2utc.pro - Takes the Atomic International Time (TAI) calculated from the 6 byte (local) on-board time from the spacecraft and converts it into UTC calendar time in one of the CDS standard formats. (Written by William Thompson, GSFC, 12 September 1993)

get_utc.pro - Gets the current date/time in UTC. (William Thompson, GSFC, 21 September 1993)

get_leap_sec.pro - Returns the dates of all known leap seconds. (William Thompson, GSFC, 21 September 1993)

read_makeShortListInput.pro - Reads in input from temporary files needed to make the SNO Short List.

transSatName.pro - Translated the satellite name from that used in the program to that used in the SNO Prediction Files place on the web.

get_spf.pro - Gets the SNO Prediction File (SPF) from the web site

read_spf.pro - Reads in input from the SNO Prediction File (SPF).

sno_prelimSearch.pro - Preliminarily identifies Simultaneous Nadir Overpasses (SNOs) of two satellite instruments from a SNO Prediction File (SPF). The SNOs identified are considered preliminary because they are deduced from predicted satellite positions, and not real satellite positions.

read_snoMasterList.pro - Reads in input from the simultaneous nadir overpass master list.

write_snoShortList.pro - Creates a file that contains a list of possible SNOs to process. Processing is handled by the separate NPOESS_SNO procedure.

sno_makeShortList.pro - configures control files, that are associating with creating a new Simultaneous Nadir Overpass (SNO) dataset from raw satellite data. The procedure includes routines to 1) obtain the latest SNO prediction file (SPF) from the ORA web site, and 2) make a list of possible new SNOs that are not found on the SNO Master List.

read_snoAcquireDataCF.pro - Reads in input from control files that contains information regarding satellites that are undergoing a simultaneous nadir overpass.

read_snoShortList.pro - Reads in input from the simultaneous nadir overpass short list.

read_dataBankLists.pro - Reads in information from databank lists regarding where to find raw satellite data for a particular time period.

get_(instr1).pro - Gets the (Instrument 1) data from the data bank prescribed in structure dataBankInfoStruct[ISAT].

get_(instr2).pro - Gets the (Instrument 1) data from the data bank prescribed in structure dataBankInfoStruct[ISAT].

get_rawSatData.pro - Accesses the satellite data bank and tests the data bank for necessary data. If the data is there, put it in local directories. If it is not, then send back a flag that will allow the main program to go to the next SNO entry from the SNO Short List.

sno_acquireDataset.pro - Obtains raw data for satellite orbital intersections that are within space and time thresholds to be considered SNO.

1a.4.1.3 Data Input/Output Files

SGP4 SOFTWARE

Input:

sat1_(satInstr)tle.dat - Two-line element (TLE) file for satellite instrument 1

sat2_(satInstr)tle.dat - Two-line element (TLE) file for satellite instrument 2

Output:

(satInstr1)_(satInstr2).txt

DATA ACQUISITION SOFTWARE

1a.4.1.4 Execution

SGP4 SOFTWARE

1) Create two TLE files. One for each satellite involved in the orbital intersection.

Example:

sat1_N17tle.dat

1 27453U 02032A 06045.89099605 .00000058 00000-0 44391-4 0 7771































































2 27453 98.6354 120.4233 0012618 72.9161 287.3402 14.23750155189374

sat1_N18tle.dat

1 28654U 05018A 06045.88084389 -.00000002 00000-0 23052-4 0 3614































































2 28654 98.7753 351.8564 0013701 205.8253 154.2220 14.10930593 38131

2) Besides the relevant TLE files, make sure that all software modules are in the appropriate directory

3) Make sure the variables are set properly in program main.c

Search for the word "Change" to find variables that need to be user defined in the program. These variables are:

t0flg=0; Flag To Perform SNO Prediction from t=Current Time (t0flg=1) or from t=Past Sat 1 TLE Time (t0flg=0)

tm_interval=1.0; Model Time Interval (seconds)

sno_timeCriteria=30.0; SNO Time Criteria (seconds)

sno_distCriteria=10.0*tm_interval; SNO Distance Criteria (km)

4) Remove the old object files

prompt> rm *.o

5) Make a new executable

prompt> make

6) Run the model

prompt> ./main (tlefile1) (tlefile2)

DATA ACQUISITION SOFTWARE

1a.4.1.5 Special Considerations

SGP4 SOFTWARE

1) Make sure that two line elements (TLE) files for each satellite contain TLEs that are matched as closely as possible in time. This means also that the two files must have exactly the same number of TLEs.

2) Make sure that only one TLE (the latest) is in each TLE file when predicting future SNOs from the current date.

DATA ACQUISITION SOFTWARE

1a.4.2 Software External Data Input

SGP4 SOFTWARE

The only data input into the SGP4 model, besides the parameters hard coded into the software driver mentioned in Section 1a.4.1.4, are the two-line elements TLEs. Current TLEs for all operational meteorological satellite instruments are available from www.celestrak.com or www.space-track.org. Celestrak does not require a registration, while Space-Track does. On the other hand, the Space-Track site does have seaching capabilities that Celestrak site does not offer.The TLEs need to be packaged in the manner of the following example below:

File Name1: sat1_(satInstr)tle.dat (eg., sat1_N17tle.dat)

File Format: ASCII Text

Input: (eg., n17 for Feb. 14, 2006)

1 27453U 02032A 06045.89099605 .00000058 00000-0 44391-4 0 7771































































2 27453 98.6354 120.4233 0012618 72.9161 287.3402 14.23750155189374 

File Name2: sat1_(satInstr)tle.dat (eg., sat1_N18tle.dat)

File Format: ASCII Text

Input: (eg., n18 for Feb. 14, 2006)

1 28654U 05018A 06045.88084389 -.00000002 00000-0 23052 4 0 3614































2 28654 98.7753 351.8564 0013701 205.8253 154.2220 14.10930593 38131  

DATA ACQUISITION SOFTWARE

1a.4.3 Software Data Output

SGP4 SOFTWARE

An example output from the SGP4 model is given below:

File Name: (satInstr1)_(satInstr2).txt

File Format: ASCII Text

Output:

Date - Date of SNO

Time - Date of SNO

SZA - Solar Zenith Angle at the time of the SNO

Latitude - Latitude of each satellite at the SNO

Longitude - Longitude of each satellite at the SNO

Space Diff - Spatial difference between between the satellites at the SNO

Time Diff - Temporal difference between between the satellites at the SNO

DATA ACQUISITION SOFTWARE

1a.5 References

SGP4 Introduction (http://en.wikipedia.org/wiki/SGP4).

SGP4 Source Code Options (http://www.celestrak.com/software/tskelso-sw.asp)

LEO-LEO SNO Intercal Process: 1b

Process Name: Collocate Pixels

Document History:

Date (yr-mon-day)	Responsible Official and Organization	Nature of Change or Revision
2009-01-05	Bob Iacovazzi, Jr. / NOAA	Original Document

1b.1 Scope

This document outlines the process used to collocate pixels from two space-borne instruments on different low-earth-orbit (LEO) satellites at simultaneous nadir overpass (SNO) events.

1b.2 Relevance to ATBD

The inter-comparison of LEO satellite instrument data at SNO events can be expedited by choosing and storing only those raw data necessary to carry out the inter-comparison. A major step in reducing the data burden of performing LEO-to-LEO inter-satellite calibration is to collocate those pixels that will be used in the analysis and discarding the remaining data. In addition, carefully determining appropriate data collocation techniques, and their associated thresholds, is critical to reducing LEO-to-LEO SNO inter-comparison uncertainties related to geolocation and resolution mismatch between measurements of different satellite instruments.

1b.3 Method Background

In the SNO analysis, bilinear-interpolation and weighted-average data collocation techniques are harnessed.

1b.4 Current Implementation

The assumptions and technical considerations to perform data collocation between LEO satellite instruments at SNO events is summarized below:

• All data chosen for the analysis are near-nadir, which eliminates the need to consider azimuthal differences between measurements from two instruments; and
• Effectiveness of bilinear-interpolation versus weighted-average data collocation techniques can be indicated by the ratio of the areas of the pixel sizes of the two instruments.

When the instrument 1 to instrument 2 ratio of the pixel areas is greater than three, then the weighted-average collocation technique is considered to be better than the bilinear-interpolation collocation technique. Note that the instrument with the larger pixel is considered to be instrument 1.

Weighted-average interpolation is carried out simply by averaging all SNO pixels from satellite 2 that fall within each satellite 1 SNO pixel. Currently, a "top-hat" weight of 1.0 is used for all satellite 2 pixels whose centers lies within the boundaries of a satellite 1 pixel, while this weight is 0.0 for all other satellite 2 pixels.

In the bilinear-interpolation collocation method. The four nearest satellite 2 pixels surrounding a given satellite 1 pixel are bilinearly interpolated to the location of the satellite 1 SNO pixel. In addition, screening collocated measurements with an indicator of the scene inhomogeneity helps to lower uncertainties in the analysis. Note that this second step is discussed in more detail in the section on Uniformity Test (3a). The reference available for the biliner-interpolation techique is Iacovazzi and Cao (2008).

1b.4.1 Software General Attributes

1b.4.1.1 Collocation Routine Authors

Date: 02/15/2006-07-11

Programmers: Bob Iacovazzi, Jr. (NOAA/NESDIS/STAR, Bob.Iacovazzi@noaa.gov) and Changyong Cao

Coding Language: IDL

1b.4.1.2 Collocation Routine Modules

SNO Make Dataset Software Architecture Flowchart

sno_makeDataset - Creates subsets of, and performs analyses on, data from Simultaneous Nadir Overpasses (SNO) of two satellite instruments. The code for procedures read_modis, read_avhrr_gac, sno, and sno_pixMatch has been edited from procedures written by Pubu Ciren and Changyong Cao of NOAA/NESDIS/ORA.

interpol_snoRawData.pro - Interpolates SNO satellite data set 2 to the pixel geolocations of SNO satellite data set 1. This code was developed from program modis2gac.pro, which was written by Changyong Cao on May 27, 2005. The method to find the correct data set 2 subregion for collocation is called Neighborhood Transverse Search (NTS).

NTS up.pro - Interpolates SNO satellite data set 2 to the pixel geolocations of SNO satellite data set 1 uprange of the SNO location nadir pixel. This code was developed from program modis2gac.pro, which was written by Changyong Cao on May 27, 2005. The method to find the correct data set 2 subregion for collocation is called Neighborhood Transverse Search (NTS).

NTS down.pro - Interpolates SNO satellite data set 2 to the pixel geolocations of SNO satellite data set 1 downrange of the SNO location nadir pixel. This code was developed from program modis2gac.pro, which was written by Changyong Cao on May 27, 2005. The method to find the correct data set 2 subregion for collocation is called Neighborhood Transverse Search (NTS).

vectorComp.pro - Computes the Cartesian vector components of two points given their latitude-longitude coordinates. This of course assumes that the points are in relatively close proximity to each other so that distances in the Cartesian coordinate system on a tangent to the earth are similar to the distances between the points on the earth.

real_distance.pro - Pixel by pixel match between two satellites modified from the original code writen by changyong for HIRS pixel by pixel

biLinear_parallelogram.pro - Interpolates data using bilinear interpolation to a parallelogram.

testCollocation.pro - This program tests the position of a data point relative to the center of a footprint. Return a flag that represents whether or not the data point is beyond (0) or within (1) the edge of the footprint.

sno_packData.pro - Finds the average of the satellite 2 data set that have been interpolated to locations of the satellite 1 data

1b.4.1.3 SGP4 Data Input/Output Parameters and Files

Definitions from Run Script

datLib="/net/orbit135l/disk2/pub/bobi/NPOESS/SNO"































































homeLib="/home/bobi/NPOESS/SNO/SUBSET_SNODATA" sat1="(Satellite 1)" and sat2="(Satellite 2)"































































Valid Satellites: NOAA06 to NOAA19 (except for NOAA 8 and NOAA13), 































































      METOP02, EOS_AQUA, EOS_TERRA, TRMM, DMSP_F10 to DMSP_F16 sat1Instr1="(Instrument 1)" and sat2="(Instrument 2)"































































Valid Instruments: NOAA&METOP-Series(AVHRR_LAC, AVHRR_GAC, HIRS3, 































































   HIRS4, MSU, AMSUA, AMSUB), METOP(IASI),EOS_AQUA(MODIS, AMSUA, AIRS_IR), 































































   TRMM(VIRS,TMI), DMSP(SSMI) Satellite Instrument Names 































































instr1Str=$sat1"."$sat1Instr and instr2Str=$sat2"."$sat2Instr 

Input:

PARAMETERS from Run Script

latDiffThresh: Latitude angle difference threshold (DEG) between two sat. nadir pixels































































lonDiffThresh: Longitude angle difference threshold (DEG) between two sat. nadir pixels































































pixDistThresh: Distance threshold (SAT PIXs) between two sat. nadir pixels































































tDiffThresh: Time difference threshold (secs) between two sat. nadir pixels 

FILES from Run Script

snoMF=$datLib"/SNO_lists/"$instr1Str"+"$instr2Str"_snoMasterList.dat": SNO Master List Files































































snoSL=$datLib"/SNO_lists/"$instr1Str"+"$instr2Str"_snoShortList.dat": SNO Short List Files































































snoNQL=$datLib"/SNO_lists/"$instr1Str"+"$instr2Str"_snoNotQuiteList.dat": SNO Not Quite List Files































































dataBankDir=$datLib"/rawDatabankLists/": Top of Raw Data Bank Listings Directory































































































































instrSpecsDir=$datLib"/SNO_instrSpecs/": Instrument Specifications Directory































































sat_rawDataDir=$datLib"/SNO_rawInput/": Local Destination Directory for Satellite Raw Data 

Output:

sat_SNOdataDir=$datLib"/SNO_rawOutput/":Local Destination Directory for SNO Subsetted Raw Data 

1b.4.1.4 SGP4 Execution

1) Create two TLE files. One for each satellite involved in the orbital intersection.

Example:

sat1_N17tle.dat

1 27453U 02032A 06045.89099605 .00000058 00000-0 44391-4 0 7771
2 27453 98.6354 120.4233 0012618 72.9161 287.3402 14.23750155189374

sat1_N18tle.dat

1 28654U 05018A 06045.88084389 -.00000002 00000-0 23052-4 0 3614
2 28654 98.7753 351.8564 0013701 205.8253 154.2220 14.10930593 38131

2) Besides the relevant TLE files, make sure that all software modules are in the appropriate directory

3) Make sure the variables are set properly in program main.c

Search for the word "Change" to find variables that need to be user defined in the program. These variables are:

t0flg=0; Flag To Perform SNO Prediction from t=Current Time (t0flg=1) or from t=Past Sat 1 TLE Time (t0flg=0)

tm_interval=1.0; Model Time Interval (seconds)

sno_timeCriteria=30.0; SNO Time Criteria (seconds)

sno_distCriteria=10.0*tm_interval; SNO Distance Criteria (km)

4) Remove the old object files

prompt> rm *.o

5) Make a new executable

prompt> make

6) Run the model

prompt> ./main (tlefile1) (tlefile2)

1b.4.1.5 SGP4 Special Considerations

1) Make sure that two line elements (TLE) files for each satellite contain TLEs that are matched as closely as possible in time. This means also that the two files must have exactly the same number of TLEs.

2) Make sure that only one TLE (the latest) is in each TLE file when predicting future SNOs from the current date.

1b.4.2 Software External Data Input

The only data input into the SGP4 model, besides the parameters hard coded into the software driver mentioned in Section 1a.4.1.4, are the two-line elements TLEs. Current TLEs for all operational meteorological satellite instruments are available from www.celestrak.com or www.space-track.org. Celestrak does not require a registration, while Space-Track does. On the other hand, the Space-Track site does have seaching capabilities that Celestrak site does not offer.The TLEs need to be packaged in the manner of the following example below:

File Name1: sat1_(satInstr)tle.dat (eg., sat1_N17tle.dat)

File Format: ASCII Text

Input: (eg., n17 for Feb. 14, 2006)

1 27453U 02032A 06045.89099605 .00000058 00000-0 44391-4 0 7771

2 27453 98.6354 120.4233 0012618 72.9161 287.3402 14.23750155189374

File Name2: sat1_(satInstr)tle.dat (eg., sat1_N18tle.dat)

File Format: ASCII Text

Input: (eg., n18 for Feb. 14, 2006)

1 28654U 05018A 06045.88084389 -.00000002 00000-0 23052-4 0 3614

2 28654 98.7753 351.8564 0013701 205.8253 154.2220 14.10930593 38131

1b.4.3 Software Data Output

An example output from the SGP4 model is given below:

File Name: (satInstr1)_(satInstr2).txt

File Format: ASCII Text

Output:

Date - Date of SNO

Time - Date of SNO

SZA - Solar Zenith Angle at the time of the SNO

Latitude - Latitude of each satellite at the SNO

Longitude - Longitude of each satellite at the SNO

Space Diff - Spatial difference between between the satellites at the SNO

Time Diff - Temporal difference between between the satellites at the SNO

1b.5 References

Iacovazzi, Jr., R. A. and C. Cao, 2008: Reducing uncertainties of SNO-estimated inter-satellite AMSU-A brightness temperature biases for surface-sensitive channels. J. Atmos. Ocean. Tech., 25, 1,048–1,054.