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

20120424: re: upcoming RUC2 -> RAP change in CONDUIT and NGRID

Hi Becky,

re:
>I was actually going to email you today on this very subject.

Great minds think alike :-)

re:
>We are 
>still very much on track for May 1st to implement the RAP.  At this 
>point, I think Critical Weather is the only thing that might stop us.

Excellent!

My plan has been to alert users one week in advance of the change and
again 1 day before the change.  If things stay on track, I will be sending
out a follow-up/second notice next Monday, April 30.

re:
>Now Tom's not going to be available on our side to implement the 
>changes, so I know we need to put in new grib tables to CONDUIT.

OK.

re:
>Can you send us the information again as to the update?

I have put an updated version g2varsncep0.tbl (revised/hacked to include
an entry for the parameter that was not being processed by 'gribinsert'
since the information needed is in a local GRIB2 table we don't have
access to) out on anonymous FTP for you to grab:

machine:   ftp.unidata.ucar.edu
user:      anonymous
pass:      address@hidden
directory: pub/gribinsert/RAP
file:      g2varsncep0.tbl

The procedure for updating toplevel CONDUIT injection machines at the
WOC is simple:

- as the user 'ldm' on the CONDUIT injection machines:

  - if it doesn't already exist, create a backup directory for
    GRIB/GRIB2 tables and save the current copy in the directory:

    <as 'ldm'>
    cd ~ldm/etc
    mkdir backup
    cp g2varsncep0.tbl backup/

- copy the new version of g2varsncep0.tbl to the ~ldm/etc directory

  See below for the steps that I would follow to do this update.

The new value will be used the next time that a slug of data is
processed into the LDM queue.

re:
>Also, would there 
>be any impact to users if we put these tables in the day before the RAP 
>went in?

Nope, none at all.

I suggest doing a 'diff' between the new version of g2varsncep0.tbl
and the one currently in use to make sure that there is only a simple
addition to the file and that there was no damage done when FTPing the
new version.  The procedure that I would follow is:

<as 'ldm'>
cd ~ldm
ftp ftp.unidata.ucar.edu
  <user> anonymous
  <pass> address@hidden
  cd pub/gribinsert/RAP
  bin
  get g2varsncep0.tbl
  quit
diff g2varsncep0.tbl etc/g2varsncep0.tbl

The 'diff' output should look like:

256,258d255
< ! Hack for 'gribinsert' for CONDUIT field not properly tagged
< 000 019 242 000 RH with respect to PW            %                    RHPW    
         0  -9999.00
< !

If it looks a lot more voluminous, then there is some problem... contact
me immediately please.

If the 'diff' output looks good, then backup the file currently in use
and copy in the new:

<still as 'ldm' in the ~ldm directory>
mkdir etc/backup
cp etc/g2varsncep0.tbl etc/backup/
mv g2varsncep0.tbl etc

re:
>Thanks.

No worries.

Cheers,

Tom

>On 4/24/2012 1:35 PM, Unidata User Support wrote:
>> Users of CONDUIT and NGRID datastream model products:
>>
>> If the current schedule remains unchanged, RUC2 grids will be replaced
>> by RAP (aka RR - Rapid Refresh) grids in the IDD CONDUIT and NGRID
>> datastreams next Tuesday, May 1 or the following Tuesday, May 8 (ref:
>> http://rapidrefresh.noaa.gov/).
>>
>> Unidata has been assured that the goal of the RUC2 ->  RAP transition is
>> to have little to no impact on end-users.  This will be accomplished,
>> in part, by keeping the model id and areal coverage the same in
>> replacement RAP products as they are current RUC2 products.  We believe
>> that a completely transparent transition will be the case for NOAAPort
>> SBN-delivered/IDD-relayed NGRID products.  However, the impact of the
>> transition on CONDUIT grids may or may not require end-user modifications
>> to LDM pattern-action file entries.
>>
>> The following is representative INFO output from the LDM 'notifyme'
>> utility captured during RUC2 ->  RAP transition testing conducted by
>> Unidata and NOAA:
>>
>> Feb 28 18:04:19 notifyme[2201] INFO:    21645 20120228180356.764 CONDUIT 000
>   data/nccf/com/rap/para/rap.20120228/rap.t12z.awp252pgrbf00.grib2 !grib2/nce
> p/RUC2/#000/201202281200F000/HGHT/1000 hPa PRES! 000000
>>
>> Note that the LDM/IDD Product ID contains somewhat contradictory
>> information:
>>
>> First part of the Product ID represents the name of the disk file
>> that the product would have on the IDD toplevel nodes at NOAA/WOC:
>>
>> data/nccf/com/rap/para/rap.20120228/rap.t12z.awp252pgrbf00.grib2
>>
>> The second part of the Product ID is created by the LDM queue insertion
>> process that cracks the GRIB2 message to get PDS values which are then
>> interpreted for Product ID information:
>>
>> !grib2/ncep/RUC2/#000/201202281200F000/HGHT/1000 hPa PRES!
>>
>> The third and last part is a sequence number.
>>
>> 000000
>>
>> The small, contradictory difference in RAP Product IDs is the appearance
>> of 'rap' in the file name portion and 'RUC2' in the "cracked" portion.
>> The continued appearance of RUC2 in the second portion of the Product ID
>> is a result of the model id being kept the same in RAP products as it
>> has been in RUC2 products.
>>
>> If CONDUIT datastream users' pattern-action file patterns use information
>> from the first or first AND second portion of the Product ID, changes
>> will need to be made.  If users' pattern-action file patterns only use
>> information from the second portion of the Product ID, no change should
>> be required.
>>
>> The following is a comparison of two 'notifyme'-listed Product IDs that
>> hopefully illustrates the effect of RUC2 ->  RAP transition:
>>
>> Existing CONDUIT RUC2 product:
>>
>> Feb 28 16:56:31 notifyme[2201] INFO:    22807 20120228165614.508 CONDUIT 024
>   data/nccf/com/ruc/prod/ruc2a.20120228/ruc2.t16z.sgrb20f09.grib2 !grib2/ncep
> /RUC2/#000/201202281600F009/CAPE/255-0 hPa PDLY! 000024
>>
>> New CONDUIT RAP product:
>>
>> Feb 28 18:04:19 notifyme[2201] INFO:    21645 20120228180356.764 CONDUIT 000
>   data/nccf/com/rap/para/rap.20120228/rap.t12z.awp252pgrbf00.grib2 !grib2/nce
> p/RUC2/#000/201202281200F000/HGHT/1000 hPa PRES! 000000
>>
>> NB: these listings are NOT for the same product/type of product
>>
>> The following is a simple example of the kind of change that one could
>> make to an existing pattern-action file pattern to accommodate the RUC2 ->
>> RAP transition:
>>
>> Existing entry for RUC2 hybrid grids:
>>
>> CONDUIT ^data/nccf/com/ruc/prod/ruc2a.(........)/ruc2.t(..)z.bgrb20.*#000
>>          FILE
>>          data/pub/native/grid/NCEP/RUC2/CONUS_20km/hybrid/RUC2_CONUS_20km_hy
> brid_\1_\200.grib2
>>
>> One way to accomodate the RUC2 ->  RAP transition is to simply replicate
>> the entry changing 'ruc' and 'ruc2' to 'rap':
>>
>> # This entry will continue to match RUC2 products
>> CONDUIT ^data/nccf/com/ruc/prod/ruc2a.(........)/ruc2.t(..)z.bgrb20.*#000
>>          FILE
>>          data/pub/native/grid/NCEP/RUC2/CONUS_20km/hybrid/RUC2_CONUS_20km_hy
> brid_\1_\200.grib2
>>
>> # This one will match RAP products
>> CONDUIT ^data/nccf/com/rap/prod/rapa.(........)/rap.t(..)z.bgrb20.*#000
>>          FILE
>>          data/pub/native/grid/NCEP/RUC2/CONUS_20km/hybrid/RUC2_CONUS_20km_hy
> brid_\1_\200.grib2
>>
>>
>> There are, of course, a number of different ways to accomodate the
>> change in Product IDs.  The best approach to use will depend on your
>> particular circumstance.
>>
>> Please send any/all questions about the upcoming RUC2 ->  RAP transition
>> to Unidata CONDUIT Support<address@hidden>.
>>
>> Cheers,
>>
>> Tom Yoksas
>> _______________________________________________
>> conduit mailing list
>> address@hidden
>> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/m
> ailing_lists/

--
********************************************************************** <
Unidata User Support                              UCAR Unidata Program <
(303)497-8643                                            P.O. Box 3000 <
address@hidden                             Boulder, CO 80307 <
---------------------------------------------------------------------- <
Unidata Web Support               http://www.unidata.ucar.edu/support  <
---------------------------------------------------------------------- <
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.