This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
According to Unidata Support: > > > 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. That's what I thought. > > 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. This might be a good approach. Alternatively, David Bright and Roz have been talking about stripping out the sigma level data into a separate gempak file. I suspect this data will end up in one of our case studies, so we will have to decide on something. > You can use GDMOD to move grids to other files that you can > create in gdcfil with MAXGRD set to an appropriate size. Jim Cowie was maintaining our GEMPAK independently from Peggy and I'm not sure we have the same defaults. In fact, since, mmhdrs in our distribution was 7K, then we are different. I think I'll try bumping back down to 10K to see how things go. In fact, I think I'll try to find your stock gemprm.* files and compare ours to yours and try to bring ours in sync. Thanks again for the help! Dave