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

19990916: Grid file full message...

Dave,

If the sizes in gemprm get changes, then the entire gemlib needs to
be recompiled so that the common blocks in the fortran programs will 
align. Moreover, anyone you wish to distribute the files to would
have to have headers at least that size.

Also, you are limited to LLMXGT grid times- which for the
ncep yearly reanalysis data is 4x per day for the entire year,
4x365 = 1460 (which exceeds the default of 1000) so I have the
dcreanal program create monthly programs to avoid that problem.
Currently, to decode the entire ensemble data (12 different runs per
forecast hour) into a single file takes approximately 9300 grids, and the
extra space can be used to compute ensemble means and statistics.

As for max stations and max times, since these are the ROW keys,
the sum of them cannot exceed MMHDRS, which is why I have
mine set at 9800 and 200. If yours are 4700 and 200 that isn't 
a problem, although the number of ship/buoy reports I get
in a file pushes the 10,000 (ship files are is 1 column, 9999 Rows).
I use a ship file for ACARS data and 1 hour will exceed 10,000.

Changing default array sizes is something I try to do only when I make
a major release since it means that everything has to be recompiled.
I increased mine from Gempak 5.2.1 and let Peggy know what sizes
I was picking. I think her dcshef will need more than 4700 stations too.

Anyhow, if the MM5 exceeds the MMHDRS that I have...and the SOOs
currently have- then I might suggest putting the forecast hours
into separate files. Since Gempak allows multiple grid files to
be searched in computations, that isn't a tremendous problem.
You can use GDMOD to move grids to other files that you can
create in gdcfil with MAXGRD set to an appropriate size.

Steve Chiswell
Unidata User Support


>From: David Himes <address@hidden>
>Organization: .
>Keywords: 199909171559.JAA17955

>According to Unidata Support:
>> 
>> Dave,
>> 
>> LLMXGD is the maximum number of grid points allowed in a single grid and
>> all your grids should have the same number of points since a grid file
>> can only contain a single projection. Our default is 100,000 gridpoints.
>> 
>> If you are exceeding the number of grids in a file, then you are
>> exceeding the number of headers allowed in a file, and you need
>> to increase MMHDRS. Presumably, your decoder program is creating
>> the gempak file with that number of headers allowed.
>
>Steve, 
>
>Thanks for the response.  David Bright, the guy who gave us the mm52gem
>program responded late last night with a similar answer.  I changed
>mmhdrs and recompiled everything and got it to decode the mm5 file into
>a gempak file.  I randomly chose mmhdrs to be 20K previously it was
>7k.
>
>This may be obvious, but if we create these GEMPAK files with large
>number of headers, then is it true that anyone that we give these
>GEMPAK files too will have to make the corresponding change to their
MMHDRS param to be able to read the files?
>
>> One other caveat, MMHDRS = LLSTFL + LLMXTM for surface/upperair files.
>> My defaults are 10,000 = 9800 + 200.
>
>Steve, are you saying that MMHDRS should equal the quantity 
>(LLSTFL + LLMXTM)?
>
>I'm looking at those parameters in our standard  gempak release and I
>see:
>
>        PARAMETER       ( LLSTFL =  4700   )
>        PARAMETER       ( LLMXTM =   200   )
>        PARAMETER       ( MMHDRS =  7000   )
>
>So, MMHDRS are not equal (LLSTFL + LLMXTM).
> 
>> Also, if you change gemprm.xxx, you also need to change gemprm.h to match.
>
>I'm glad you mentioned this...  I thought about that last night, but
>didn't make the corresponding change to the C header.  The program
>worked, but it may have been just dumb luck that it didn't segment
>fault somewhere.
>
>Dave
>