[McIDAS #HZP-657281]: Moving McIDAS-XCD server

Hi Hsie,

re:
> I begin to receive and file NGRID data on stratus.al.noaa.gov.

Very good.

> I can the see the data coming in.  But I am not sure I file them properly.

I turned off processing of NGRID data on stratus yesterday or the evening
before because of a problem that was encountered.  I have not yet had time
to get back to investigating what I saw.

>Could you shed some light on the naming convention for the GRIB file.
> 
> I can figure some but not all of them:
> 
> GFS.80.2007255.0.0.38.grib
> GFS.81.2007255.1200.0.201.grib
> 
> There are 7 columes:
> 
> (1) Model name
> (2) Model ID
> (3) year and Julian day
> (4) hour and minute (?)
> ...
> 

There are three different possibilities for naming the files written
to disk; these three are set in $MCDATA/GRBFILER.CFG:

TITLEFLAG=3               # if set to 0 specific, model,run-time dependent
                          # grid file title is built.
                          # if set to 1 generic title with run-time in it.
                          # if set to 2 generic title, no run-time
                          # if set to 3 same as 0 but prepended with model name

stratus used the default naming, TITLEFLAG=3.  The meaning of the pieces of
the name for option 3 as defined in the procedure Mcgribtofilename contained
in ~mcidas/mcidas2007/src/Mcgrbbfrdec.c are:

1) model name (as defined in $MCHOME/data/gbtbpds001.av1)
2) model ID
3) Julian date [CCYYJJJ]
4) model runtime [UTC]
5) field valid time [UTC]
6) grid geographic ID (e.g., 211 grid; 236 grid; etc.)
7) GRIB type: '.grib' -> GRIB1
              '.grb2' -> GRIB2

Note that most, if not all, of the GRIB messages contained in the NGRID
datastream are in GRIB2 format while all of the GRIB messages currently
contained in the HDS datstream are in GRIB1 format.  The clock is ticking
on the transition from GRIB1 to GRIB2; in the not too distant future (early
next year?), all GRIB messages will be in GRIB2 format.

By the way, I reported the problem we encountered in running 'xcdscour'
yesterday afternoon.  Before doing this, we (actually Mike Schmidt) determined
that the cause of the problem is likely related to the following SunSolve
entry:

  Bug ID: 4956673
  Synopsis: mktime won't allow TZ offsets in hours of greater than 167 hours
  Category: library
  Subcategory: libc
  State: 11-Closed
  Description:

  mktime won't accept TZ offsets of greater than 167 hours any more.
    Date Modified: 2004-06-11 05:50:40 GMT+00:00

  Work Around:

  Do the math by hand.
    Date Modified: 2004-06-11 02:45:39 GMT+00:00

As you can see, Sun's "work around" is to do the calculations by hand :-O

I think that the best solution for McIDAS in general is to rewrite 'xcdscour'
as a Tcl script.  The work in calculating the list of Julian dates to use in
scouring is trivial in Tcl, and it is not constrained to a 10 day window
like is the case currently in 'xcdscour'.

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: HZP-657281
Department: Support McIDAS
Priority: Normal
Status: Closed