Assistant Technical Representative: John E. Janowiak

Contributors: Robert J. Joyce

Period of Performance: November 3 - 9, 2001

1. WORK PERFORMED DURING THE PAST WEEK

A. Precipitation derived from the AMSU-B sensor aboard both the NOAA-15 and NOAA-16 satellites has a limb problem which is most often characterized as "blocky" precipitation overestimation yielding strong discontinuities parallel to the track of the satellite, reflecting strong satellite zenith angle gradients at the edge of the swath. After careful inspection of the AMSU-B limb problem, a method was developed to trim the edges of both the NOAA-15 and NOAA-16 swaths. For the NOAA-15, the original swath width is 19 degrees of longitudinal coverage at the equator, and increases at ~ 1/cos(lat) toward the poles. A 130 km (~1.2 deg longitude at equator) trim from each side of the NOAA-15 swath boundary is used to remove the discontinuities, (seen in the below mentions eps

files) this means more pixels at the mid-latitudes than at the equator. For the NOAA-16 which has a original swath width of 22 degrees of longitudinal coverage at the equator, the limb problem extends a little more earth distance into the swath, thus a 150 km (~1.35 deg lon at equator) trim is used. About ~85-88% of the original earth coverage of the AMSU-B derived precipitation remains. Three eps files were uploaded to the ftp.ncep.noaa.gov, in the data/rjoyce/amsu-b_trimmed directory. Two show the before and after of the AMSU-B trim correction at different latitudes, the other eps file is a larger coverage view giving a good indication of the remaining coverage.

B. The next task is to tackle the problem of requiring the geostationary satellite ID (and IR information to be used) is the same for each 5x5 latitutde /longitude regions within each pair of successive IR images to be used for spatial lag correlation. To begin this process, code has been added which obtains geostationary satellite ID from the 0.5 degree IR products along with the full res IR images in the software used to derive the zonal and meridional half-hourly advection vectors from IR and then advects microwave derived precipitation. Next we need to set criteria to determine geostationary satellite advection zones, logistically how to derive half-hourly advection vectors from one-hourly imagery of the GMS, and how to deal with temporal gaps in geostationary satellite data for purposes of deriving advection vectors.

2.	WORK PLANNED FOR NEXT WEEK

A. Take a look at the idea of creating daily/(6 hourly?) templates of most used satellite ID for each 5x5 latitude/longitude region (from 0.5 degree IR products files) to be used as criteria for the satellite ID determination of current processing day usage.

Points to consider:

- What happens when one satellite is "out" for the past day and our scheme tries

to look for that satellite's data in 5x5 boxes in the overlap regions?

- This would eliminate the usage of another satellite's data in overlap regions during equinox periods.

- Do we help ourselves my dumping the full resolution IR imagery to disk for the

even and odd satellite configuration?, it could be easily done. Currently we only

use the best satellite for a full resolution merge product. Advantages would include: 1. greater domain for each satellite, 2. also there is no overlap, so each 5x5 region could only have data from one satellite, day in, day out, 3. SatID already available for even and odd satellite configuration in 0.5 degree product file. Downside would be space and file management problems, and possible continuity problems in regions where derived advection vectors are temporally swinging in and out from derivation from different satellites.

B. Also, once a scheme to determine satellite ID for a 5x5 region has been developed, code in the advection software needs to modified to use only that satellite's 8 km pixels within each 5x5 region of both successive IR images for spatial lag calculation.

C. The next logistical step is to determine how to perform spatial lag correlation on one hourly GMS images in code set up to process on a half-hourly basis, and the reduce those vectors to half-hourly amplitude.

Points to consider:

- What do we do for GMS domain regions like the S.H. for which we only get an image every 3 hours? Should we set up the software to be flexible enough to handle spatial lag correlations at various time intervals between successive images and then reduce the vector amplitudes to half hourly levels?