Data Applications

General

The Global Precipitation Measurement (GPM) mission is an international network of satellites that provide the next-generation global observations of rain and snow. For details, visit: http://pmm.nasa.gov/GPM

July 14th – GMI Level 2 Precipitation Rate data will be released. This includes precipitation rates estimated using the Goddard Profiling algorithm (GPROF14) and are available as swath data.

Early September – DPR Level 2 precipitation rate data will be released via PPS and JAXA. This includes three-dimensional swath data from the DPR Ka and Ku-band radars.

Mid-September - The DPR-GMI Level 2 combined product will be released

January 2015 – NASA’s Level 3 Integrated Multi-Satellite Retrievals for GPM (IMERG) will be released with all available data. This gridded product will have a resolution of 0.1 degrees and updated every 30 minutes from 60⁰N-60⁰S.

What is the naming convention for GPM products?

The naming convention is in this document: http://pps.gsfc.nasa.gov/Documents/FileNamingConventionForPrecipitationProductsForGPMMissionV1.4.pdf

The GES DISC currently has several different access methods for the data. You can view these methods and further information at the Data Holdings interface.

The GES DISC primary search and download interface, Mirador, is available at http://mirador.gsfc.nasa.gov/

Can I use OPeNDAP to download GPM data?

Yes, http://gpm1.gesdisc.eosdis.nasa.gov/opendap/

Data Formats, Tools and Visualization

What format are GPM data in?

They are stored in HDF-5 format, and they follow the netCDF format model, making them usable in many netCDF-compatible software packages.

Any tools to convert GPM HDF5 data to NetCDF?

The netCDF-4/HDF5 format was introduced in version 4.0; it is the HDF5 data format, with some restrictions (from Wiki). The HDF Group provides very useful software and services: http://www.hdfgroup.org/HDF5/

The HDF files can be directly added to the software but the geolocation info is not recognized. Additional manipulation is needed after the data are added. We advise users to use only the netCDF files through OPeNDAP or follow an additional recipe to perform the HDF manipulation which will be released soon!

How can I import and geolocate the 0.1-degree resolution IMERG native HDF5 file in ENVI?

3.Edit the output data’s hdr file, using either “Raster management -> Edit ENVI Header” or any text editor, to include the “map info” and “coordinate system string” information, as shown in the following example:

I am using the 3-hourly 3B42 rainfall rates from TRMM. How can I convert these 3-hourly rainfall rate (mm/hour) to total daily rainfall (mm/day)?

The 3B42 rain rate is a 3-hourly average centered at the middle of each 3-hour period (i.e., 0Z, 3Z, 6Z, 9Z, 12Z, 15Z, 18Z, and 21Z). To convert these rainfall rates to total daily rainfall, first multiply each 3-hourly rainfall rate by 3 hours, to get the total rainfall for each 3-hour period. Then, for your desired 24-hour-day begin and end times, sum all the 3-hourly total rainfalls in your defined 24-hour period, to get the total daily rainfall.

What is the TMPA (3B42, 3B43) grid structure?

Each 3B42 file contains a 3-hourly estimate and each 3B43 file contains a one-month estimate. The grid on which each field of values is presented is a 0.25 deg x 0.25 deg latitude--longitude (Cylindrical Equal Distance) array of points over the latitude range 50N-S. It is size 400x1440, with X (latitude) incrementing most rapidly South to North, and then Y (longitude) incrementing West to East from the Date Line. Grid edges are located at whole-degree values:

First point center= (49.875S,179.875W)

Second point center = (49.625S,179.625W)

Last point center= (49.875N,179.875E)

The same grid-box definition applies to the RT and to the monthly.

What are the values for latitude and longitude in TRMM 3B42 and 3B43 HDF data files?

The data in the HDF file are written in the following order, (-49.875, -179.875), (-49.625, -179.875), (-49.375, -179.875), (-49.125, -179.875)......(49.875, -179.875), (-49.875, -179.625), (-49.625, -179.625)...... The dimension for longitude is 1440 and the dimension for latitude is 400. The value used to indicate missing data is "-9999.9".

The GES DISC/DAAC receives, under normal circumstances, processed standard orbital/swath data products about 2-3 days after satellite data acquisition, depending on the level of processing required. In addition to this ongoing collection of data, archives of older data are maintained.

TRMM V7 3B43 and 3B42 data product availability will be delayed for a period of 2 to 3 months. For example; the 3B42 and 3B43 V7 products for May 2012 would not be available until August 2012 due to the extra inputs, variables and quality control measures. According to Dr. George Huffman, "The pacing item is the precipitation gauge analysis. In Version 7 we moved to using the GPCC "monitoring analysis", which is relatively high-quality and consistent with the GPCC "full analysis" that only appears a few years after the observation time. In previous versions we used the NOAA CAMS analysis, which gave better timeliness, but recently proved to differ from the expected patterns in the GPCC "full analysis" due to upgrades in the latter."

What is the GES DISC/DAAC Search and Order Web Interface?

The GES DISC/DAAC data search and order interface is a simple point-and-click web interface that is based on a hierarchical organization of data, displayed as tables. At different levels of the hierarchy, the tables contain some or all of the following: a particular data product grouping such as data product name, year, or month in the first column on the left; followed by columns of short description, begin date, end date, number of items available in the archives, average item size, a preview feature (if a data product has browse images), and documentation ("readme"). The last column on the right allows one to "Select" an item. At certain levels of the hierarchy, you can also use orbital and parameter search features to customize your search.

Information about algorithms used for the TRMM products can be found in the Algorithm Status Page, where the links to the products take you to brief descriptions of the status of the products and, for some products, key references.

I would like to receive all new files generated for a data product, over a given time period, at a specified time interval (e.g., weekly). Can I set up a procedure by which specified data will be sent to me automatically?

Yes, just contact help@disc.gsfc.nasa.gov (or 301-614-5224, voice; or 301-614-5268, fax) and request a "subscription." Information that would be needed from you are data product(s) desired, begin date, and end date. You will receive an email notification whenever data are ready for FTP pickup.

How are the daily products computed from 3B42RT and 3B42 in TOVAS?

These daily products are computed by accumulating all the estimates available in the eight observation times of a given UTC day, namely 00, 03, ..., 21 UTC. Formally, this "day" covers the period from 2230 UTC of the previous day through 2230 UTC of the given day. Other "day" products can be computed interactively for 3B42RT and 3B42 by specifying similar 8-period runs of data. For example, a day that starts at 09 UTC can be approximated by taking data from 09 UTC of one day through 06 UTC of the next. At present, there is no capability in TOVAS for a more exact approximation of a "day" for these data sets.

What’s the difference between the real time and research products of the TRMM Multi-satellite Precipitation Analysis (TMPA)?

The Near-Real-Time TRMM product *3B42RT* is being computed with the TMPA in near-real-time, and constitutes the most timely source of TMPA estimates. The near-real time computation requires several simplifications in 3B42RT compared to 3B42:

The complete 3B42RT data record is not reprocessed as upgrades are made to the procedure – its main focus is timeliness.

The IR calibration period is a trailing 30-day accumulation, rather than the calendar month in which the observation time falls.

A real-time version of the TMI is used as the calibrating standard because the TRMM Combined Instrument product (2B31) is not available in real time.

In near-real time it is not possible to apply precipitation gauge data.

Note that 3B42 estimates are considered to supersede the 3B42RT estimates as each month of the 3B42 data are computed during the following month. The 3B42 processing is designed to maximize data quality, so 3B42 is strongly recommended for any research work not specifically focused on real-time applications.

What are the caveats in using TRMM Multi-satellite Precipitation Analysis (TMPA) products?

The following are some caveats in using TMPA:

The key caveat is that all of the TMPA products are research products, not "operational" in the sense of hot spares, contingency plans, and backup machines waiting to take over in the event of a failure. Looking back through the RT news, the prospective user should get the sense that the system could run for months at a time, but if there's a network failure or a disk crash, it might take days to fix, particularly over weekends or holidays.

The TMPA is a gridded product, which is different from the point rain gauge data more familiar to some users. On the other hand, grid values might be more appropriate for certain applications than are point values from rain gauges.

Although the TMPA analysis scheme is consistent for the time period of a given version, the suite of input data varies. For example, there is less of the (higher-quality) microwave data before 2001 or so; the infrared data are on a coarser grid in 1998-1999; gauge sites report individually, and, therefore, are subject to availability issues, particularly in developing countries.

Occurrence of precipitation over land tends to be underestimated, because satellite schemes tend to miss light precipitation and precipitation that is enhanced by flow lifting over mountains.

Occurrence and amount of precipitation in some, but not all, coastal areas tend to be underestimated. Conversely, arid coastal areas (oceans and lakes) sometimes show persistent artifacts. Both effects are due to issues in the input microwave estimates.

The RT amounts tend to be biased high in warm-season convective weather due to biases in the input microwave estimates.

The Version 6 amounts tend to be biased low in regions of complex terrain due to gauge-location biases toward lower elevations.

Can I see an example of a GrADS ctl file for TRMM Level-2 and Level-3 HDF data?

The following document provides examples of ctl files. These examples may be useful to TRMM data users familiar with GrADS.

In a TRMM 3B42 file name (e.g., 3B42.19980115.00.7.HDF.Z) the "0" in the file name following the date (MMDD) indicates the midpoint of a 3-hour interval. In the example filename, the "00" indicates 00:00Z. So the data in this file were acquired commencing at 22:30Z (1/14/1998) and ending at 1:30Z (1/15/1998). The precipitation quantity is the average rain rate calculated over this 3-hour interval. Note that the "Z" in the filename indicates that the file is compressed with Unix compression and does not designate a time. Thus, the 3B42 filename template is 3B42.YYYYMMDD.<midpoint of a 3-hour interval>.<version #>.HDF.Z

How can I read the TRMM binary files in TOVAS?

The following read programs in Fortran can be applied to TRMM TOVAS binary files. For some products, an adjustment to the array size is needed.

Because the total days in each month are different, mm/hr is used for easy comparison. Since the 3B43 product is a monthly average, you could simply do the conversion by multiplying the hourly rain rate with the total hours in that month.

Is there any software to convert radiance to brightness temperature?

VIRS L1B Radiance Converter

The 1B01 Calibration software creates an alternative VIRS L1B product. It converts the 1B01 radiances to percent albedo for visible channels, and to brightness temperatures for thermal channels. The output has the same HDF format as the 1B01 product, and all 1B01 parameters except radiances are carried over.

The software is written in C. The PPS/TSDIS toolkit and a few HDF routines are used and included in this software package.

The VIRS L1B converter can be obtained using the PPS/TSDIS anonymous FTP site:

For the TRMM 2A25 data product, Is the 80th level located at 250m height, 79th at 500m ...and so on ...?

The range bin numbers in the output of 2A25 are all relative to the Earth's ellipsoid with the ellipsoid range bin corresponding to 79. For example, if the range bin number is 75, its height from the ellipsoid is (79-75)*0.25 = 1.0 km. This number is NOT the height above the actual surface.

For TRMM 3B43, 3B42, it seems there are two datasets (HDF and binary) with different latitude, longitude arrangements. Is this true? Which one should I use?

Yes and both are arranged differently. The HDF is the standard TRMM archive format and data are written in the following order, (-49.875, -179.875), (-49.625, -179.875), (-49.375, -179.875)...... The binary are written for GrADS (a free popular software used in climate and weather communities) and in (-49.875,-179.875), (-49.875,-179.625), (-49.875,-179.375°W)...... Apparently if you are a GrADS user, you should use the binary. Otherwise, there is a list of software in http://disc.sci.gsfc.nasa.gov/precipitation/additional/tools

Why there is an extra "A" in 3B42 and 3B43 file names after May 2007?

Due to changes in the AMSU calibration, all 3B42 and 3B43 granules starting in May 2007 and continuing for the remainder of the Version 6 processing cycle will now have the designation "6A" to indicate this change.

Full announcement for TRMM Data Users - Due to changes in the AMSU calibration, all 3B42 and 3B43 granules starting in May 2007 and continuing for the remainder of the Version 6 processing cycle will now have the designation "6A" to indicate this change. One of the inputs to 3B42 and 3B43 is AMSU-B data processed by NOAA. NOAA began processing with a new version of their algorithm May 31, 2007 around 1800 UTC. 3B42 and 3B43 had to change to use the new AMSU-B. Since both 3B42 and 3B43 use data from the entire month, all 3B42 and 3B43 for May 2007 forward have the filename version 6A and the algorithm version 6.43.

4) Select Geographic Lat/Lon in both input/output Porjection of Geometry Bands. Click OK. Select 0 degree rotation in output and click Memory in Output Result to. Note: it can take a long time to process.

6) Select a band from the list in the newly generated memory and click Load Band. You will see the geolocated map. Right click the image and select Cursor location/values... to see data values for each pixel.

From http://disc2.nascom.nasa.gov/tovas/: 1. Scroll down to the "Rainfall Archives" list. 2. Select the "Non_Java Version" for "3B42 V7". 3. Type in the latitude/longitude of the location as both the West/East and North/South limits. 4. Choose "Accumulated Rainfall (mm)" or "Rain Rate (mm/hr)" 5. Choose the plot type "Time Series, Area-averaged". 6. Enter the year/month span for which you want data. 7. Click on "ASCII Output".

The latent heating products of TRMM 2A12 and 3A12 over ocean surfaces should be regarded as experimental. Please confer first with the algorithm developers (by contacting the GES DISC) when using the latent heating product over the ocean. Over-land latent heating estimates from TRMM products 2A12 and 3A12 should not be used, as they have not been evaluated quantitatively or qualitatively.

The IR data prior to February 2000 covers the span 40° North to 40° South. After and including February 2000, the data cover 50° North to 50° South. This results in a minor discontinuity in the data record. Also, HQ data sources are introduced at different points in the data record. Therefore, variations in HQ coverage will occur throughout the record, increasing as time progresses. Most critically, the introduction of AMSU-B data causes a low bias of almost 10% globally.

The accuracy of the precipitation products can be broken into systematic departures from the true answer (bias) and random fluctuations about the true answer (sampling), as discussed in Huffman (1997). The former are the biggest problem for climatological averages, since they will not average out. However, for short averaging periods the low number of samples and/or algorithmic inaccuracies tend to present a more serious problem for individual microwave data sets. That is, the sampling is spotty enough that the collection of values over (for example) one day may not be representative of the true distribution of precipitation over the day. For VAR, the sampling is good, but the algorithm likely has substantial RMS error due to the weak physical connection between IR Tb's and precipitation.

Accordingly, the "random error" is assumed to be dominant, and estimates could be computed as discussed in Huffman (1997). Random error cannot be corrected.

The "bias error" is likely small, or at least contained. This is less true over land, where the lower-frequency microwave channels are not useful for precipitation estimation with our current state of knowledge. The state-of-the-art at the monthly scale is reflected in the study by Smith et al. (2006). Studies of the sub-monthly bias have not yet been performed.

Note: For IDV, (1) Increase memory to 2048 MB allocated to IDV using instructions from the IDV FAQ: http://www.unidata.ucar.edu/software/IDV/docs/userguide/Faq.html#memory (2) In Data Chooser, select General->URLs and type/paste in the URL: http://disc2.nascom.nasa.gov:80/dods/MergedIR (3) In Field Selector, lower right, check "Times" and then uncheck "Use Default". Check to display only one time. (4) Still in Field Selector, lower right, check "Stride", and then select "Every third point" (5) Click "Color-Shaded Plan View" in upper right of Field Selector. (6) Click "Create Display"

Very likely your machine is Little Endian. The binary data are in Big Endian and the sample read code in the PDF is for Big Endian machines. You need to add extra code for conversion if your machine is Little Endian, such as,

Since the rays are slant path, the latitude and longitude of a given bin that is above the Ellipsoid will move inwards towards the center of the swath. At distances of 15km above the Ellipsoid bin this correction is on the order of a ifov.

For the 1st column of the data array, the latitude is fixed at 24.375. There are 8 data elements in this column and their corresponding longitudes are listed at the bottom of the output. Based on this info, the geolocation for the 1st element (1.44) is (24.375, -93.375), the 2nd (24.375, -93.125)......

The same can be applied to the output from OPeNDAP (http://disc.sci.gsfc.nasa.gov/services/opendap/TRMM/trmm.shtml).

If you are interested in subsetting and converting to ASCII the TMPA data, we have developed a new service that allows you to accomplish this through a URL call. Below is a sample of a URL and the required inputs:

Why there is an extra "A" in V7 3B42 and 3B43 file names between January 2000 and September 2010?

It was recently discovered that AMSU data were neglected in the first retrospective processing of both the Version 7 TMPA (3B42/43) and TMPA-RT (3B40/41/42RT) data series, which creates an important shortcoming in the inventory of microwave precipitation estimates used during 2000-2010. In addition, a coding error in the TMPA-RT replaced the occasional missings in product 3B42RT with zeros. Accordingly, both product series are being retrospectively processed again. The main impact in both series should be to improve the fine-scale patterns of precipitation during 2000-2010 (and for 3B4xRT into late 2012). Averages over progressively larger time/space scales should be progressively less affected. [This is the reason the lack of AMSU went undiscovered; the merger system copes very reasonably with missing data.] Nonetheless, users are urged to switch to the newest Version 7 data sets as soon as they are computed and posted (in the next few weeks). The newest runs may be identified by the file names: V.7 3B42/43 suffix of "7A.HDF" for January 2000 - September 2010 V.7 3B4xRT suffix of "7R2.bin" for 1 March 2000 - 6 November 2012 It continues to be the case that the Version 7 3B42/43 is some 5-8% higher than the calibrating data set (2B31) over oceans, which is believed to be erroneous. However, the first several attempts at diagnosing this issue have not been fruitful. At the large scales this offset seems to be nearly a proportional constant.

Please note that if you plan to download the GrADS ready V7 3B42/43 from ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/, the "A" has been removed from the file name because our applications can't support different file name templates.

How can I extract rainfall data from an irregular area?

1) If you have commercial GIS software, follow this link, http://disc.sci.gsfc.nasa.gov/precipitation/additional/faq/precipitation-faq#ArcGIS

2) If you are a GrADS user, convert your irregular area into a mask and apply this mask to rainfall data. If you have a shapefile, you can use software such as gdal (http://www.gdal.org/) to make the mask, for example,

First type in the geolocation information (latitude, longitude) of the point in the "Area of Interest" and update the map; select a time period and "Time Series" to generate a plot. The output time series files in HDF, NetCDF and ASCII are available in "Download Data".

d) Download original files in HDF and write your own software (i.e., IDL, Matlab, GrADS, etc.) to extract time series. You can use SSW (http://disc.sci.gsfc.nasa.gov/SSW/) or Mirador to download the data.

Can I download TRMM (3B42, 3B43) data with just one NetCDF?

Using ncks, TRMM data can be downloaded with one NetCDF file, for example,

Is there any README and software for the TRMM Composite Climatology (TCC) products?

The TRMM Composite Climatology (TCC) of Tropical Rainfall September 2010

There are 78 data files in this directory: 13 each (annual and month-of-year) for 2A12, 2A25, 2B31, 3B43, TCC, and standard deviation of TCC. The file name means: <type>.<month>.<TRMM version>.bin Each file is one grid, and the grid is 0.5 degree. The data are from west to east starting from 0.25E (720 grids), and north to south starting from 35.75N (144 grids).

It is hoped that this new climatology will be useful as a summary of surface rain estimates from TRMM (not replacing the individual products) and will be useful to the user community as a ready comparison with other non-TRMM analyses and for comparison with numerical models, including those used for retrospective "re-analysis" and for climate simulations.

How do the IR calibrations for 3B42 and 3B42RT differ?What is planned in this regard for GPM?

A whole calendar month is used for IR calibration in 3B42, while it's the trailing approximate 30 days for 3B42 RT.The calendar-month approach works for 3B42 because it's processed about 2 months after observation time, so the entire month of data has been observed by the time computation occurs.More precisely, the RT calibrations are accumulated on pentad (5-day) periods.So, the calibration period is the previous 5 whole pentad periods and whatever of the current pentad period has occurred.This is done for computational simplicity.

If we take 5 May 2010 as an example, 3B42 uses calibrations based on 1-31 May 2010, while 3B42RT uses calibrations based on 6 April 2010 (The beginning of the 5th-earlier pentad) to the observation time on 5 May 2010 (which happens to be the last day of the current pentad).

Looking to the GPM era, we're shifting the timing for IR calibration in the GPM multi-satellite products, which are collectively called IMERG; see

.All RT and "final" versions will have calibration windows that slide along as time progresses, but the "Final Run" will have a window that extends about 2 weeks into the future (again, because processing happens 2 months later, so all the "future" data are recorded).

1. The 3B42 calendar-month IR calibration is sort of a historical artifact, due to the fact that 3B42/43 is processed a calendar month at a time.For GPM, in the new IMERG Final Run the IR calibration will be a centered 30-day period, recomputed once a pentad.

2. The new IMERG Final Run will continue to use calendar-month calibration to the gauges because the monthly gauges are accumulated on calendar months.

3. The new IMERG RT will continue to use a trailing approximate 30-day calibration, since you can't reach into the future.

What is the repeat cycle of TRMM?

46 days and it changes 24 hours of local time in 46-day procession cycle.

Is there any information about the TRMM temporal sampling of tropical regions?

# The example is tested in ArcMap 10.2.1. It can be copied and # pasted into the ArcGIS python window to test run.

# The example get a entire data array without performing spatial subsetting # To get spatial subset. Users can change the array indices in the # example's "var" part using the following correspondence between row/column # indices and the latitude/longitude: # There are 400 rows (from 0 to 399), representing # latitudes from -49.875 to +49.875 at 0.25 increment. NOTICE that the # centre coordinate of the first row, row 0, is at the south (-49.875). # There are 1440 columns (from 0 to 1439), representing longitude from # -179.875 to +179.875, at 0.25 increment.

On October 07, 2014, routine production ended for the TRMM PR precipitation estimates.Since PR is no longer available, the TMI/PR combined instrument (TCI) estimates are also no longer available.As products 3B42/3B43 use the TCI estimates as the satellite calibrator, September 2014 is the last month these products were produced in this way.In an effort to continue 3B42/3B43 available and usable, the real time TMPA (TMPA-RT) climatological calibrations/adjustments have been adapted for use in the 3B42/3B43.October 2014 is the first month of the climatologically calibrated/adjusted 3B42/3B43.Users should note there will be a discontinuity in the record as a result.Each individual user must determine the most appropriate use of the climatologically calibrated/adjusted 3B42/3B43 products.

The two-month latency for 3B42/3B43 remains the same with this new calibration.The delayed release for October 2014 reflects both development work and a problem with the input IR data.The previously released "provisional" data set is now considered obsolete and should not be used (although in many areas it is identical to this official release).As well, a (different) problem with the input IR for November 2014 is not yet resolved, so that data set is still in provisional status.We expect to have updated November 2014 IR data in the very near future, and thereafter run on the usual schedule.

In Product 2A25 the variable "errorRain" is expressed in decibel(dB). I would like to know how to relate this to the corresponding measurements in "e_SurfRain" and "nearSurfRain", which are in mm/h. Is it possible to convert the dB into mm/hr?

I can obtain from the file specifications document the differencesbetween how the “e_SurfRain” and “nearSurfRain” variables are obtained. However, what would you recommend is the variable most directly comparable to ground-based radar?”

Answer: The two estimates of rainfall rate differ in that the nearSurfaceRain is constructed from a measured reflectivity just above the clutter region. The clutter region is ray angle dependent.The estimated e_SurfRain uses assumptions on the reflectivity profile down to the surface to estimate the rainfall rate below the clutter region.Which to use depends on the application. The estimated surface rain was an attempt to better match the rainfall seen by sensors like the radiometers (TMI) since they sense path integrated quantities and have no clutter region 'dead space'.

Since ground radar measurement location is a function of distance from the radar it depends on your application. Some users choose to select data from a specific height (say 2km or 4km above the Ellipsoid) to avoid clutter issues.