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

20060123: Gempak - GEMPAK to IDV conversion?

>From: "John Meyers" <address@hidden>
>Organization: Boston Museum of Science
>Keywords: 200601231850.k0NIoT7s012642 IDV ADAS

Hi John-

I was tied up in a meeting the last couple of days, so sorry for
the delay in responding.

>Very intersting.  This was the first thing I tried when I started
>messing with ADAS over the summer.  I was able to get netCDF output, but
>it was not structured in the way that IDV requires.  I will revisit this
>with the current version of ADAS (v5.2.4).  I am curious though if you
>are using some sort of additional post-processing step to get the output
>into an IDV-usable netCDF, or just setting the history dump format
>option to netCDF and reading the xxx.cdf00000 file with IDV?

Here's what I was told:

> All they needs is ARPS 5.2.4.  In the ADAS input file, set "hdmpfmt" to 7.
> This requires that no input data be HDF4 format, and that the ADAS binary
> be built that way.

If that doesn't answer your question, let me know.  You'll need 
to be running IDV 1.3b1 to support this format.

>> You should be able to put the GRIB files in the catalog and
>> point to them with the IDV.  The latest THREDDS Data Server (TDS)
>> supports this through OPeNDAP, but you should also be able to 
>> reference them as dataType GRID and serviceType netCDF in the
>> catalog.
>
>Another thing I did not know.  Thanks!  However, there is a potential
>caveat here.  How would I do this if I have non-WMO defined parameters
>here?  

Each IDV installation would need to have access to a file called
grib1lookuptable.lst which would list the parameter table.  The
format is:

<center>:<subcenter>:<version>:  <table location>

so it would look like:

57:     1:      2:      gwctab_2.tab

You can read more information about this at:

http://www.unidata.ucar.edu/software/decoders/javadoc/Parameters.txt

It hasn't made it's way to the IDV User's Guide yet.

Once you've created this file, IDV users could use it by putting
the grib1lookuptable.lst in their <home>/.metapps/DefaultIdv
directory and put the corresponding table files where they
are pointed to in the file.  This can be a relative path or
a web server.  Alternatively, you could place the grib1lookuptable.lst
and associated parameter tables on a local web server and have
the users use the IDV's sitepath parameter (startup option or
user preference) to point to the location where the files are.

>Also, Is there a reason that the public THREDDS server on
>motherload hosts all the HRS and CONDUIT data as netCDF over GRIB? And
>finally, we are archiving this data on a large storage array, and I
>worry about long-term usability of the data.  I hope that because of the
>self-descriptive format that data stored today as netCDF will be
>decodable well into the future.  I'm hesitant to say the same for
>GRIB....

I think GRIB is more self describing than netCDF.  Grib has specific 
(although numerous) rules, where anyone can store anything in
a netCDF file any way they choose.  (Thus our problems reading
the old ADAS formats).

>By the way, thanks for chiming in on this one!

No problem.  Let me know if you have more questions.

Don Murray
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.