[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19991007: followup on MRF grids (2 vs 3)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 19991007: followup on MRF grids (2 vs 3)
  • Date: Thu, 7 Oct 1999 14:46:14 -0600

Jim,

Both grid 2 and 3 are available on NMC2 from 0-168 hours,
and just grid 2 thereafter. Note also, that due to the fire
on the Cray at NCEP, the current run for today was through 240 hours
rather than 384 hours.

As you mention, the file naming changes for the grid 2 files from NCEP
at the 184 hour point. Where from 0-168 they have the .2 identifier
and thereafter it is omitted.

The .2 files were tagged as originating from the ensemble MRF runs,
which hasn't been available since the fire- and I don't see those
files in the OSO ftp directory at:
ftp://140.90.6.103/ncepb/mrf/mrf.991007/

If you see the .2 files somewhere else today, then please let me know and
I can contact NCEP to see why they aren't getting posted.

I tried to outline the MRF grid 2 vs 3 file naming at:
http://www.unidata.ucar.edu/staff/chiz/ncep_idd/mrf_files.html

For 0-168 grid 2, you should see the headers:
/public/ncepb/mrf/ens/YYMMDD/drfmr.THHZ.PGrbFff.2

then for 184-384:
/public/ncepb/mrf/mrf.YYMMDD/drfmr.THHZ.PGrbFff

Steve Chiswell
Unidata User Support


On Thu, 7 Oct 1999, W James Steenburgh wrote:

> Steve:
> 
>       Oops, a couple of typos in that previous email concerning 
> the MRF 2 grid.  The data is only available at and after forecast
> hour 180, not 184.  As a quick note, on the OSO server, grib
> files for all times before 180 have a ".2" suffix.  I am not sure
> if this would have anything to do with why we are not getting the
> data via the ldm feed, but perhaps it plays a role.
> 
> Thanks again,
> 
> Jim
>