[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CONDUIT #NLP-275663]: SREF upgrade testing
- Subject: [CONDUIT #NLP-275663]: SREF upgrade testing
- Date: Tue, 24 Jul 2012 16:20:19 -0600
Hi Carissa,
re:
> For your downloading pleasure (FYI, only 24 hours of data are kept)
>
> CC = 03, 09, 15, 21
>
> Model #113 - mean and spread (both got [GB 1] errors)
> ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/sref/para/sref.YYYYMMDD/CC/ensprod_biasc/sref.tCCz.pgrb212.(mean|spread)_3hrly.grib2
>
> Model #111 - NMB (currently labeled as WRF_EM)
> ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/sref/para/sref.YYYYMMDD/CC/pgrb_biasc/sref_nmb.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
>
> Model #112 -NMM (currently labeled as WRF_EM)
> ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/sref/para/sref.YYYYMMDD/CC/pgrb_biasc/sref_nmm.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
Thanks this was very helpful indeed.
Review of what we discussed during our testing this afternoon:
ModelId Label Files
---------+---------+--------------------------------------------------------------
111 NMMB
pgrb_biasc/sref_nmb.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
112 NMM
pgrb_biasc/sref_nmm.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
113 SREF_113
ensprod_biasc/sref.tCCz.pgrb212.(mean|prob|spread)_3hrly.grib2
116 WRF_EM I don't have a URI for these
I downloaded all files for 20120724_0900 today from the FTP site you referenced
above. Using 'wgrib2' I found that the ModelID ('wgrib2 -processid') in the
various
types of output is, in fact:
ModelID Label Files
---------+---------+--------------------------------------------------------------
116 NMMB
pgrb_biasc/sref_nmb.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
116 NMM
pgrb_biasc/sref_nmm.tCCz.pgrb212.(ctl|p1|n1|p2|n2|p3|n3).grib2
113 SREF_113
ensprod_biasc/sref.tCCz.pgrb212.(mean|prob|spread)_3hrly.grib2
116 WRF_EM I don't have a URI for these
My point is that the ModelIDs for the NMMB and NMM grids are all 116 not 111
and 112,
respectively. So, the 'gribinsert' code was labeling the products appropriately
given its mapping of ModelID to name:
[ModelID]
case 111: return s_model_id("NAM",model);
case 112: return "WRF_NMM";
case 113: return s_model_id("SREF",model);
case 114: return "NAEFS";
case 115: return s_model_id("DGEX",model);
case 116: return "WRF_EM";
(the routine s_model_id("SREF",model) returns SREF_113 for products with a
ModelId
of 113, etc.)
Now the question is why the ModelIds for NMMB and NMM are 116 instead of
111 and 112, respectively?
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: NLP-275663
Department: Support CONDUIT
Priority: High
Status: Open