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

[McIDAS #JIN-832252]: cannot get MySQL database working with GRIB data



HI Robert,

re: using DMGRID to decode AMPS grids
> DMGRID did seem to work.  Unfortunately it took the MM5 and WRF
> and each different resolution (there are 5 different ones) and out
> them all into one 2+GB file, so I will have to work on that,

OK.  The good news, however, is that the grids are being decoded.

I have to agree that the formalism in RTMODELS.CFG is a bit awkward,
so it takes some time to get the desired configuration.

>So it seems that the database method should work.

Very good.  This should also mean that the grids would be individually
decodable by the gribdec.tar.gz package I told you about previously.

> Anytime you get between now and 16 Nov to look at the MySQL issue,
> just let me know and I will test whatever you need me to test.

I verified that the mysql flag value was not even attempted to be used
in the McIDAS makefile.  Adding support for it shouldn't be too hard.
I will take a look after my workshop ends next Thursday.

> Thanks for your help!

No worries.

> Unfortunately it looks like there is not enough info for McIDAS to be
> able to tell the MM5 and WRF, and the 5 different resolutions apart.
> GEMPAK does this with the pqact entry getting info from the header.

You could do the same by using the gribdec.tar.gz stuff to decode individual
grids from one or more pqact.conf entries.  It may take some playing around,
but it should work with not too much difficulty.

> The output is from the raw GRIB files of the WRF and MM5, respectively.
> As you can see, they are identical.

To me this signals a deficiency in the AMPS creation of the grib messages.
After all, the model being used should be contained in the grib message
itself (as model ID).

> I guess I could decode WRF on one machine and MM5 on the other as a way
> around it..

That would work, but it feels kludgy.

> /usr2/config% grdlist.k AMPS/ARW-D3 FORM=ALL
> Dataset position 1      Directory Title= /2006102612_D3.grb
> PAR  LEVEL      DAY          TIME     SRC  FHR  FDAY         FTIME    GRID  
> PRO
> ---- ---------- ------------ -------- ---- ---- ------------ -------- ----- 
> ----
> CWMR     2 M    26 OCT 06299 12:00:00 NCAR    0 26 OCT 06299 12:00:00     1 PS
> Total pts= 102960 Num rows= 312  Num columns= 330   received:  2006300 202856Z
> Cloud Water Mixing Ratio
> GRIB ID numbers: Geographic =  255; PAR =153; Model ID =255; Level type =105
> Units of gridded variable are KGKG Scale of variable is:   2
> Polar Stereographic Projection
> Row num of pole=  170.58  Col num of pole=  168.48  Col spacing (m)= 19182.0
> Standard Latitudes=  -60.00    -60.00   Standard Longitude=  180.00
> Number of grids listed = 1
> GRDLIST - done
> /usr2/config% grdlist.k AMPS/MM5-D3 FORM=ALL
> Dataset position 1      Directory Title= /2006102612_D3.grb
> PAR  LEVEL      DAY          TIME     SRC  FHR  FDAY         FTIME    GRID  
> PRO
> ---- ---------- ------------ -------- ---- ---- ------------ -------- ----- 
> ----
> CWMR     2 M    26 OCT 06299 12:00:00 NCAR    0 26 OCT 06299 12:00:00     1 PS
> Total pts= 102960 Num rows= 312  Num columns= 330   received:  2006300 202940Z
> Cloud Water Mixing Ratio
> GRIB ID numbers: Geographic =  255; PAR =153; Model ID =255; Level type =105
> Units of gridded variable are KGKG Scale of variable is:   2
> Polar Stereographic Projection
> Row num of pole=  170.57  Col num of pole=  168.52  Col spacing (m)= 19182.0
> Standard Latitudes=  -60.00    -60.00   Standard Longitude=  180.00
> Number of grids listed = 1
> GRDLIST - done
> /usr2/config%

Seems to me that the AMPS guys should be made aware of this situation.  One
quick "solution" for McIDAS DMGRID processing would be to set the model ID
for the MM5 version to be 255 (or 254), and the WRF version to be 254 (or 255).
One could then create appropriate RTMODELS.CFG entries to decode the output
into different GRID file number ranges.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: JIN-832252
Department: Support McIDAS
Priority: Normal
Status: Closed


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.