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

Re: eta gempak files (fwd)

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: eta gempak files (fwd)
  • Date: Wed, 12 Sep 2001 10:55:24 -0600 (MDT)
Hi Tom, 

I feel your pain.

When using the FTP option, CODIAC assigns "unique" names to the files to
avoid confusion. This is a real problem for software that is looking for
specific file names. I have used awk scripts, etc. to reaname these files.

What we have done in the past..(a real pain, I know!) Is to use gdinfo to
evaluate the files and then re-name them appropriately.

i.e.

GEMPAK-GDINFO>l
 GDFILE   = /home/jweber/test/jwebeAAA0z2sOw
 LSTALL   = YES
 OUTPUT   = T
 GDATTIM  = list
 GLEVEL   =  
 GVCORD   =  
 GFUNC    =  
 GEMPAK-GDINFO>r

 GRID FILE: /home/jweber/test/jwebeAAA0z2sOw                                    
                                                            

 GRID NAVIGATION: 
     PROJECTION:          LCC                 
     ANGLES:                25.0   -95.0    25.0
     GRID SIZE:           93  65
     LL CORNER:              12.19   -133.46
     UR CORNER:              57.29    -49.38

 GRID ANALYSIS BLOCK: 
      UNKNOWN ANALYSIS TYPE 

 Number of grids in file:   154

 Maximum number of grids in file:   1500


 List of times: 

 001121/0000F000


Enter a time or type EXIT:

After getting all the file times and runs from this process they can be
renamed. I am sure this could be scripted, but if this is your only
exposure to the FTP route it may not be worth the time sink. Or....you can
order the complete tape, with the runs in GRIB, and pass the GEMPAK
decoders over the GRIB files...

Or even quicker and easier, order via ftp the GRIB formatted files then
cat them and run them through dcgrib2 to generate appropriate .gem files

Given you have GEMPAK , I would suggest ordering the grib data and then
processing them to .gem files via dcgrib, or preferably, dcgrib2.

And if none of these options work or make sense, I -may- be able to do the
conversions today for you and make them available via ftp.

I apologize for this inconveniance and, trust me. I have been trying to
work around this issue in CODIAC for years...maybe in the next release. 


Look forward to your feedback,

-Jeff
____________________________                  _____________________
Jeff Weber                                    address@hidden
Unidata Support                               PH:303-497-8676 
NWS-COMET Case Study Library                  FX:303-497-8690
University Corp for Atmospheric Research      3300 Mitchell Ln
http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
________________________________________      ______________________

On Wed, 12 Sep 2001, Ron Murdock wrote:

> Jeff -
> 
> This one is for you I think.
> 
> Ron
> 
> ---------- Forwarded message ----------
> Date: Wed, 12 Sep 2001 11:23:51 -0400
> From: Thomas Niziol <address@hidden>
> To: address@hidden
> Subject: eta gempak files
> 
> Hello:
> 
> I downloaded and unzipped eta model files for case study 32 in what I
> assumued to be gemapk format.  I expected i would get a .gem file that
> could be opened in GARP for viewing the model.  The file naming
> convention is usually MMDDYY_modelname.gem.  However, all of these files
> are only about 1meg long and do not follow any naming convention.  Other
> model runs such as mm5 are OK from this case study.  What do i have to
> do to these files to produce one big .gem file for viewing in GARP?
> 
> Tom Niziol
> NWSFO Buffalo, NY
> 
> 
>