[OB7.2 Task Description for "Provide RFC QPE Grids for WFO
D2D"]{.underline}

NWS/Office of Hydrologic Development/HSEB

11/21/2005

Updated 04/28/06

[1. Background]{.underline}

The RFC Hydrology Program is responsible for generating river forecasts,
which are heavily dependent on detailed quantification of estimated
precipitation. The ability of the RFC Hydrometeorologic Analysis and
Support (HAS) staff to relate the estimated precipitation to other
hydrometeorological data sets improves their understanding of the
precipitation event. This need was addressed in AWIPS OB6 with the
addition of the ability to display locally generated hourly 4-km
HRAP-based gridded estimates within the D2D application.

This feature allows a given WFO and RFC to visualize their own locally
generated grids. The usefulness of the generated grid is dependent on
the quality control performed on the radar, gage, and satellite data
used to generate the resulting grids. Although some WFOs perform this
quality control, most do not because it is requires time and detailed
knowledge of the sensor characteristics and prevailing
hydrometeorological characteristics. Therefore, the resulting RFC
Quantitative Precipitation Estimated (QPE) grids are generally of higher
quality than WFO QPE grids, although they may not be produced as quickly
as they are produced at WFOs.

[2. Need]{.underline}

This OB7 task involves the need to have the WFO Hydrology Program
benefit from having the RFC hourly QPE grids for: a) use in local
headwater models, and b) for situational awareness; i.e. interpretative
analysis and display in assessing flooding threats and general
precipitation patterns in their area of responsibility. Because these
data serve as critical input to the RFC river forecast models, the HAS
staff at RFCs perform routine QC on these data sets. In order to meet
the fundamental need to provide the best grids for a WFO, the need
exists to transfer the RFC QPE grids to WFOs whose area is covered by
the RFC area, and to make these grids available to WFO operational
software.

The focus of this need is on hourly QPE information. Shorter interval
data is currently not used for headwater and river flooding needs. The
FFMP algorithm is the primary WFO application which uses shorter
interval QPE data; its needs are not addressed in this task.

[3. Requirements]{.underline}

To satisfy this need, a sequenced set of operations must be performed.
The requirements for these operations can be grouped by the following
functional areas. All grids are assumed to hourly QPE grids on the 4km
HRAP polar stereographic grid.

1)  Generate RFC grids

2)  Transmit RFC grids to WFO

3)  Ingest and decode RFC grids at WFO

4)  Mosaic multiple RFC grids into super-grid and crop to WFO size

5)  Store WFO grids derived from RFC grids for use in WHFS applications

6)  Provide for display of RFC grids in D2D display software

7)  Provide for display of RFC grids in WHFS display software

8)  Provide for usage of MAP data in WHFS applications

OB6 D2D will be capable of displaying locally generated 1 hour QPE
products on the 4 km HRAP grid. These are created by OHD processes in
GRIB format in the OHD directory
/awips/hydroapps/precip_proc/local/data/mpe/qpe_grib. It then provides a
copy in the /data/fxa/Grid/SBN/Raw directory and invokes the
/awips/fxa/bin/notif_mpe.csh process to notify the GribDecoder process
that a file is ready to be processed. The decoded netCDF files are
placed in the directory

/data/fxa/Grid/SBN/netCDF/local/MPE

[4. Similar Existing Capabilities\
]{.underline}

These requirements would expand on existing capabilities in the D2D
software. Specifically, D2D is already capable of displaying gridded 1,
3, 6-hour FFG mosaics which are on the 4km HRAP grid. D2D can also
display 6-hour QPE mosaics; it is understood that these mosaics are
generated locally from individual 4km HRAP grids within AWIPS.

Also, these operations are similar to those exercised in a recently
introduced system for displaying NWS QPE data via an experimental
website at <http://www.srh.noaa.gov/rfcshare/precip_analysis_new.php>.
This "system" is comparable to the proposed system except that instead
of a AWIPS-internal D2D display it is a public web page display. Both
have the issues of decoding, mosaicing, cropping, and displaying the QPE
information.

The operational concept being considered is similar to the existing
transfer of data to the NCEP NPVU (National Precipitation Verification
Unit), which receives QPE data from RFCs and posts them to its web
sites. For examples, see:

http://www.hpc.ncep.noaa.gov/npvu/data/

<http://www.hpc.ncep.noaa.gov/cgi-bin/npvu.data.cgi>

[5. Operations Concept Design]{.underline}

The table below attempts to identify the lead and participating
development organizations for each sub-task, and includes a brief
discussion of the task.

+----+------------+-----+--------------------------------------------+
| *  | *Summary*  | *Le | *Discussion*                               |
| Su |            | ad* |                                            |
| b* |            |     |                                            |
|    |            |     |                                            |
| *t |            |     |                                            |
| as |            |     |                                            |
| k* |            |     |                                            |
+----+------------+-----+--------------------------------------------+
| 1  | Generate   | RFC | Generated by RFCs in xmrg format. A given  |
|    | RFC QPE    |     | hour's grid may be sent more than once     |
|    | grids      |     | (2-3 times) as grids are refined           |
|    |            |     | throughout the day. Xmrg format converted  |
|    |            |     | to GRIB1 format by OHD grib encoder for    |
|    |            |     | transmission.                              |
+----+------------+-----+--------------------------------------------+
| 2  | Transmit   | OHD | Transmit over SBN, use WMO ZETA98 product; |
|    | RFC grids  |     | product category of QPE (?). OHD will      |
|    | to WFO     |     | provide a script to RFCs to invoke         |
|    |            |     | distributeProduct() to upload the data to  |
|    |            |     | the SBN to selected destinations for       |
|    |            |     | selected hour(s).                          |
+----+------------+-----+--------------------------------------------+
| 3  | Ingest and | GSD | Using acq_patterns filter, capture and     |
|    | decode RFC |     | decode GRIB1, store as netCDF. Will/should |
|    | grids at   |     | filter allow distant RFCs grids to be      |
|    | WFO        |     | rejected? As described in SMM 6.2.2.1,     |
|    |            |     | decoded netCDF stored at:                  |
|    |            |     | /data/fxa/img/SBN/netCDF/HRAP/QPE          |
|    |            |     |                                            |
|    |            |     | OHD will want the quantitative data for    |
|    |            |     | use in river models. Need to make sure     |
|    |            |     | that this is stored in the netcdf. The     |
|    |            |     | destination directory is not cast in stone |
|    |            |     | and may change.                            |
+----+------------+-----+--------------------------------------------+
| 4  | Mosaic     | O   | Upon arrival of grid, mosaic with          |
|    | multiple   | HD/ | available neighbor RFC grids. FSL          |
|    | RFC grids  |     | currently does some mosaicing of RFC QPE   |
|    | into       | G   | products, so maybe we could expand that    |
|    | super-grid | SD? | function. Stored files will need to be     |
|    | and crop   |     | purged as part of routine FXA data purging |
|    | to WFO     |     | operations. (Like ECMWF currently -- Jim   |
|    | size       |     | Ramer. As long as valid time stamp stays   |
|    |            |     | the same) No data value 1e+37. Jim will    |
|    |            |     | double check software for stitching        |
|    |            |     | together to make sure not to overwrite a   |
|    |            |     | "good" value with a no-data flag value     |
|    |            |     | when there are overlaps on the mosaic.     |
|    |            |     |                                            |
|    |            |     | What do we do if there is overlap of two   |
|    |            |     | areas with valid data?                     |
+----+------------+-----+--------------------------------------------+
| 5  | Store      | N/A | This step is unnecessary as it is assumed  |
|    | WFO-size   |     | that the cropping will be done on the fly. |
|    | grid for   |     | However, if it required for other users,   |
|    | use in     |     | it will be used by adjusting the           |
|    | WHFS       |     | GenArealFFG capability, which already      |
|    | ap         |     | exists. It does a similar operation for    |
|    | plications |     | FFG data.                                  |
+----+------------+-----+--------------------------------------------+
| 6  | Provide    | GSD | Allow display of RFC(s) grids in D2D.      |
|    | for        |     | Place the new option under the NCEP/Hydro  |
|    | display of |     | menu, under QPE\|1hr MPE Precip; add       |
|    | RFC grids  |     | option for RFC Image and RFC Contour,      |
|    | in D2D     |     | similar to existing options for Local      |
|    | display    |     | Image and Local Contour.                   |
|    | software   |     |                                            |
+----+------------+-----+--------------------------------------------+
| 7  | Provide    | OHD | This would use existing methodologies to   |
|    | for        |     | display the data.                          |
|    | display of |     |                                            |
|    | RFC grids  |     |                                            |
|    | in WHFS    |     |                                            |
|    | HydroView/ |     |                                            |
|    | MPE Editor |     |                                            |
+----+------------+-----+--------------------------------------------+
| 8  | Provide    | OHD | Read data and compute MAP for usage in     |
|    | for usage  |     | SiteSpecific application.                  |
|    | of RFC     |     |                                            |
|    | grids in   |     |                                            |
|    | WHFS       |     |                                            |
|    | A          |     |                                            |
|    | pplication |     |                                            |
+----+------------+-----+--------------------------------------------+

[6. Action Items]{.underline}

1)  OHD will check with GSD whether the 6-hour QPE mosaics in D2D are
    generated locally from 4km HRAP grids within AWIPS or are generated
    by NCEP processes external to AWIPS.

2)  OHD will check whether OHD gribit encoder app assigns special
    indicator value for a missing value. The Precipitation Analysis web
    page uses a mask file to indicate the actual area of coverage. AWIPS
    software recognizes special value (1EE+37) in the GRIB data as the
    missing value indicator. \[XMRG files use -1 for no coverage
    areas.\]

3)  OHD will provide some estimates of data storage requirements based
    on the number of grids, size of grids, etc. This can consider
    alternatives such as whether to store entire nation or just the
    office area, and whether to store only 1-hour amounts, or multi-hour
    accumulations.

4)  OHD will learn basic usage of AWIPS volume browser tool for
    displaying multi-hour accumulations. Until OB8, these multi-hour
    data sets must be generated using the volume browser, as opposed to
    having them generated a-priori and having multi-hour options built
    into the D2D menu. If time permits, consider adding 6, 12, 24 hour
    accumulations for synoptic times in the menu options.

5)  OHD will contact JeffZ regarding filtering with acq_patterns if
    necessary. Filtering would prevent grids from distant RFCs from
    being processed. Since all RFCs will use the same ZETA98 WMO header,
    it is not clear how this filtering will differentiate RFCs.

6)  If time resources are limited, prefer to have display enabled in the
    following scales (most important listed first): wfo scale, regional
    scale, national scale.

END OF DOCUMENT