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

Re: 20041214: dcgrib2 error - Grid too large 65535 x 512 [33553920 > 750000]

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.

  • Subject: Re: 20041214: dcgrib2 error - Grid too large 65535 x 512 [33553920 > 750000]
  • Date: Tue, 14 Dec 2004 13:34:08 -0600

Ok, Yeah, I think it is a gaussian grid, thanks for the info.

Pete

In a previous message to me, you wrote: 

 >
 >Pete,
 >
 >If I read your wgrib output correctly,
 >the GDS type 4 is a gaussian grid which GEMPAK does not
 >handle regardless of number of points since the GEMPAK
 >grid library uses regularly spaced rows.
 >
 >When dealing with larger grids in general, you can define LLMXTG
 >to the size of the input grid, while using LLMXGD as the largest
 >subset of the LLMXTG for viewing and using the IJSKIP parameter.
 >
 >The ndfd decoder does support a GSKIP parameter for subsampling
 >the input grib2 data, which is something I'll try to
 >support in dcgrib2 in the future, but since you seem to
 >have gaussian grids, that isn't going to solve your problem here.
 >
 >Steve Chiswell
 >Unidata User Support
 >
 >
 >>From: address@hidden (Pete Pokrandt)
 >>Organization: UCAR/Unidata
 >>Keywords: 200412141831.iBEIVXlI009124
 >
 >>--------
 >>
 >>Steve,
 >>
 >>A user of ours has some ECMWF grib files from an archive that he
 >>cannot decode. The problem appears to be that the input grid
 >>is too large. Is there any way to increase the dimensions, or
 >>to have dcgrib2 decode only over a limited domain?
 >>
 >>The command used to convert was:
 >>
 >>cat mrz02_142_143.grb | /home/gempak/GEMPAK5.7.2p2/bin/linux/dcgrib2 -d ./te
  >st
 >> .log -e GEMTBL=/home/gempak/GEMPAK5.7.2p2/gempak/tables mrz02_142_143.gem
 >>
 >>The error message I get is:
 >>[14912] 041214/1128 [DCGRIB -55] Grid too large 65535 x 512 [33553920 > 7500
  >00
 >> ]
 >>
 >>The grib file appears to be a 1/3 degree global grid, thinned in the x direc
  >ti
 >> on, so there are 512 points from SP to NP, and 1024 around the equator, wit
  >h
 >>fewer in the x direction as you move away from the equator.
 >>
 >>From grads 'wgrib', I have the following info:
 >>
 >>rec 1:0:date 2002010400 LSP kpds5=142 kpds6=1 kpds7=0 levels=(0,0) grid=255 
  >sf
 >> c ECMWF stream? 24hr fcst:
 >>  LSP=Large scale precipitation m
 >>  timerange 0 P1 24 P2 0 TimeU 1  nx -1 ny 512 GDS grid 4 num_in_ave 0 missi
  >ng
 >>  0
 >>  center 98 subcenter 0 process 199 Table 128
 >>  thinned gaussian: lat  89.731000 to -89.731000
 >>     lon 0.000000   348528 grid pts   (-1 x 512) scan 0 mode 0 bdsgrid 1  nl
  >at
 >> :
 >>      18   25   32   40   45   50   60   64   72   72   75   81   90   96  1
  >00
 >>     108  120  120  125  135  144  150  160  160  180  180  180  192  192  2
  >00
 >>     216  216  216  225  240  240  243  250  256  270  270  288  288  288  3
  >00
 >>     300  320  320  320  324  360  360  360  360  360  360  375  375  384  3
  >84
 >>     400  400  400  432  432  432  432  432  450  450  450  480  480  480  4
  >80
 >>     480  486  500  500  500  512  512  540  540  540  540  540  576  576  5
  >76
 >>     576  576  576  600  600  600  600  600  640  640  640  640  640  640  6
  >40
 >>     640  648  675  675  675  675  675  675  720  720  720  720  720  720  7
  >20
 >>     720  720  729  729  750  750  750  750  750  768  768  768  768  800  8
  >00
 >>     800  800  800  800  800  800  810  810  864  864  864  864  864  864  8
  >64
 >>     864  864  864  864  864  864  864  900  900  900  900  900  900  900  9
  >00
 >>     900  900  900  960  960  960  960  960  960  960  960  960  960  960  9
  >60
 >>     960  960  960  960  960  960  960  960  960  960  972  972  972  972  9
  >72
 >>    1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 10
  >00
 >>    1000 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 1024 10
  >24
 >>    1024 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 10
  >00
 >>    1000 1000  972  972  972  972  972  960  960  960  960  960  960  960  9
  >60
 >>     960  960  960  960  960  960  960  960  960  960  960  960  960  960  9
  >00
 >>     900  900  900  900  900  900  900  900  900  900  864  864  864  864  8
  >64
 >>     864  864  864  864  864  864  864  864  864  810  810  800  800  800  8
  >00
 >>     800  800  800  800  768  768  768  768  750  750  750  750  750  729  7
  >29
 >>     720  720  720  720  720  720  720  720  720  675  675  675  675  675  6
  >75
 >>     648  640  640  640  640  640  640  640  640  600  600  600  600  600  5
  >76
 >>     576  576  576  576  576  540  540  540  540  540  512  512  500  500  5
  >00
 >>     486  480  480  480  480  480  450  450  450  432  432  432  432  432  4
  >00
 >>     400  400  384  384  375  375  360  360  360  360  360  360  324  320  3
  >20
 >>     320  300  300  288  288  288  270  270  256  250  243  240  240  225  2
  >16
 >>     216  216  200  192  192  180  180  180  160  160  150  144  135  125  1
  >20
 >>     120  108  100   96   90   81   75   72   72   64   60   50   45   40   
  >32
 >>      25   18
 >>  min/max data -2.6846e-17 0.302269  num bits 16  BDS_Ref -2.6846e-17  DecSc
  >al
 >> e 0 BinScale -17
 >>
 >>You can grab the input grib file for testing if that helps, from
 >>http://sysadm.aos.wisc.edu/~poker/jan02_142_143.grb
 >>
 >>Thanks for any info or advice!
 >>
 >>Pete
 >>--
 >>+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
 >>^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
 >>^ Systems Programmer               V Madison,         WI     53706    ^
 >>^                                  V      address@hidden       ^
 >>^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
 >>^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
 >>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
 >>
 >--
 >**************************************************************************** 
  ><
 >Unidata User Support                                    UCAR Unidata Program 
  ><
 >(303)497-8643                                                  P.O. Box 3000 
  ><
 >address@hidden                                   Boulder, CO 80307 
  ><
 >---------------------------------------------------------------------------- 
  ><
 >Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
  ><
 >---------------------------------------------------------------------------- 
  ><
 >NOTE: All email exchanges with Unidata User Support are recorded in the
 >Unidata inquiry tracking system and then made publicly 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.


--
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
^ Pete Pokrandt                    V 1447  AOSS Bldg  1225 W Dayton St^
^ Systems Programmer               V Madison,         WI     53706    ^
^                                  V      address@hidden       ^
^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (Phone/voicemail) ^
^ University of Wisconsin-Madison  V       262-0166 (Fax)             ^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+