Re: 20001220: number of times in file in nmap2

Tom,

Yes, you can get around this with individual (YYYYMMDDHHNN) files.

The Radar Coded Message GRIBS come out 2x per hour (under the HRS feed
header HAXA00 KWBC). These are all stored as analysis fields. The
dcgrib2 defaults I provided in $GEMTBL/grid/gribkey.tbl will
place them into daily files.

For forecast model grids, generally you are looping a series of forecasts
from an initial time, eg ETA F000-F060. So, each forecast run is in a single
file. In the case of RCMG  data, you will be looping a series of initial times
(F000). Storing all the RCMG data in daily files just makes use in programs
easier.

Steve Chiswell
Unidata User Support

On Wed, 20 Dec 2000, Tom McDermott wrote:

> On Wed, 20 Dec 2000, Steve Chiswell wrote:
> 
> > I encountered similar problems when placing all the radar coded message
> > grids (HAXA00 KWBC) in a single daily file.
> 
> Steve,
> 
> Could you get around this (if your fix was not available) by having hourly
> files?  Is there some reason why you would want to have all of a day's
> grids in a single file?
> 
> Tom
> ------------------------------------------------------------------------------
> Tom McDermott                         Email: address@hidden
> System Administrator                  Phone: (716) 395-5718
> Earth Sciences Dept.                  Fax: (716) 395-2416
> SUNY College at Brockport
> 
> 
> > The problem was the length of the string that is used to return all the 
> > times
> > in a file. In the 5.6.A release I made yesterday:
> > $GEMPAK/source/programs/gui/nmap2/nmap_dslw.c,
> > you will find in: void dslw_layerSet(layer)
> >
> >  * Chiz/Unidata         12/00   Increased gdclst size 1024->4096        *
> >
> > You can see if this value is large enough, or you need to increase it
> > some more.
> >
> > Steve Chiswell
> > Unidata User Support
> 
>