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

20040310: How to increase the times that GDSTAT can process

Jongnam,

After looking at the code, I see where MXLOOP is being set
as the upper limit, but after looking at the gempak library,
the only hard limitation is the number of grid times
in the GR_FTIM call which is LLMXGT (1000), so that should
get changed. That is already the limit for the number of
grid times in a gempak grid file.

But, 1000 times may be too small for what you want 
assuming 30 years times 365 days per year * x number of times 
per day (unless you are using monthly averages already).

The calculation limit for AVG, STD, MAX, MIN really is not limited
by any of these factors. The only reason for the limit is the need
to get the list of times.

I would be willing to either recompile the program without the MXLOOP
bug if that suits you, or investigate a way around the GEMPAK library
limit of 1000 LLMXGT.

Steve Chiswell
Unidata User Support



>From: Jongnam Choi <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403101345.i2ADjUrV012460

>Dear. Steve
>
>How to increase the times that GDSTAT can process. 
>It is strange that the upper limit is 30,
>although I set 610800/0000-980801/0000.
>
>Following is a message
>
>[GR 5] Too many frames in the windows, set to MXLOOP.
>GDSTAT PARAMETERS
>
>Found 30 grids from 30 selected times.
>Times: 610800/0000        - 900801/0000
>Maximum grid name:            MAXHGHT
>Minimum grid name:            MINHGHT
>Average grid name:            AVEHGHT
>Standard deviation grid name: SDVHGHT          
>Count grid name:              CNTHGHT  
>
>I use the GEMPAK.5.6_linux version.
>
>Sincerely
>
>Jongnam Choi
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.