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

Re: Extended GFS 0.5 degree data

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: Extended GFS 0.5 degree data
  • Date: Tue, 13 Jun 2006 13:59:34 -0500
In a previous message to me, you wrote: 

 >Pete,
 >
 >I mentioned the .status file since an SSEC user had a similar problem
 >with the grid #3 data going to XCD where the pattern did not prevent
 >that ascii inventory from getting to their decoder.

Yep, I'm in contact with Jerry and Steve Wanzong down there, also
trying to figure this all out.

 >
 >The performance issue of decoding higher resolution data is valid
 >(as is decoding the same data at multiple resolutions).

I am now running into some slowdown issues even on my faster machine
when decoding grib2 to gempak. I do have everything running on
a single SATA raid10 array, which may be slowing things down some.
I am hoping in the next day or two to throw in a SCSI drive to hold
the ldm queue to keep it separate I/O wise from the saved and decoded data.

Also, I'm running the dcgrib2 decoder from GEMPAK version 5.8.2. Have
there been speedups/optimizaitons in newer versions that might cut
down on the speed of GRIB2 decoding? Maybe if I compile locally with
optimizations turned on or something?

I have not yet had a chance to look at the .status files issue or to
compare my files with yours. That's hopefully this afternoon.

 >As always, please feel free to contact me with problems you might be
 >encountering with the data stream and/or software since these are
 >the problems that will affect many others as well.

Ok, I definitely will. This is becoming more urgent with the potential
cutover to only GRIB2 both at NCEP and on the IDD (well, the same thing
really :)

Thanks,

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)             ^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+