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.
>From: David Himes <address@hidden> >Organization: . >Keywords: 199909171414.IAA11145 > >Hello, > >We are trying to convert an mm5 output file to gempak. The convert >program is called mm52gem and it uses GEMPAK API's for file output. >The mm5 output files our huge (650Mb). We're getting a message > > "[GD-11] Grid file is full" > >towards the end of the conversion (working on the 48'th hour). Is >there a GEMPAK parameter that controls how big a GEMPAK file can be or >how many grids can be written to it? I seem to recall something about >a limit, but on searching the GEMPAK support pages and Peggy's soo/sac >pages, I am unable to find anything. I thought perhaps llmxgd looked >like a possibility, but upon changing that and recompiling everything, >I get the same problem. > > >Thanks in advance... > >-- > >Dave > 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. One other caveat, MMHDRS = LLSTFL + LLMXTM for surface/upperair files. My defaults are 10,000 = 9800 + 200. Also, if you change gemprm.xxx, you also need to change gemprm.h to match. Steve CHiswell