[Met_help] pcp_combine, trouble reading GRIB
John Halley Gotway
johnhg at rap.ucar.edu
Tue Jul 29 12:09:32 MDT 2008
Matt,
I have access to the NCEP machine VAPOR. And I could try building MET on it to see if there are any problems. Do you have any idea if VAPOR is set up similar to the machine on which you're trying to
build MET? Would it be worthwhile for me to try to build it on VAPOR?
John
matthew.pyle at noaa.gov wrote:
> Hi John,
>
> I confirmed that the BIGENDIAN flag is set, and that it is being
> respected within the vx_grib_classes processing. An endian-issue had
> come to mind earlier, but I don't see why some information would be
> properly extracted from GRIB while other data wouldn't. Getting MET
> running is a fairly low-priority item for me (nobody has a gun to my
> head, just playing with it on the side), but if you have suggestions for
> a next step in figuring out the problem, I'd be happy to give it a try.
>
> Regards,
>
> Matt
>
> John Halley Gotway wrote:
>> Matt,
>>
>> I'm guessing it's a big vs. little endian issue. The LINUX machines
>> on which we developed MET are all little endian. But then when we got
>> MET up and running on bluevista and bluefire (NCAR's IBM's), we had to
>> add support for big endian. We found that MET would compile on the
>> IBM with the wrong endian selected - but we'd get garbage data from
>> the GRIB files, which is exactly what you're seeing.
>>
>> In the top-level MET Makefile for an IBM, the architecture flags are
>> set as follows:
>> ARCH_FLAGS = -DIBM -DBIGENDIAN
>>
>> So just make sure that that's how it's set in your top-level
>> Makefile. And I assume your IBM is big endian.
>>
>> The ARCH_FLAGS variable is used in the sub-makes but only in 3 of the
>> libraries (vx_grib_classes, vx_util, and vx_wrfdata). On our IBMs,
>> passing it to the compiler in those places was sufficient. However,
>> it's possible that we'd need to pass it in additional Makefiles on
>> your IBM for some reason.
>>
>> Sorry for the issues you're encountering, but support for IBMs is new
>> for METv1.1. So I'm not surprised that there are hiccups. Hopefully
>> we can straighten them out.
>>
>> John
>>
>> matthew.pyle at noaa.gov wrote:
>>> Hi,
>>>
>>> I got everything to compile okay, but am not having success with the
>>> pcp_combine tests. I get garbagey (1e+30) kinds of values for the
>>> precipitation totals in the resulting netCDF files, and the bad
>>> information appears to be coming from the GRIB. Turning up the
>>> verbosity, I see some proper PDS/GDS information from the GRIB, along
>>> with some bad values. Any ideas why some of the GRIB information
>>> appears to be read okay, while other parts are not? I'm doing this
>>> work on an IBM. A few diagnostic snippets are below.
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>> lat1: 12190
>>> lon1: 8522067 <--- should be -133459 (or 226541 E)
>>> res_flag: 8
>>> lov: 8483608 <--- should be -95000 (or 265000 E)
>>> dx: 40635
>>> dy: 40635
>>> pc_flag: 0
>>> scan_flag: 64
>>> latin1: 25000
>>> latin2: 25000
>>> lat_sp: 0
>>> lon_sp: 0
>>>
>>> ===================================================
>>>
>>> Grib Record:
>>>
>>> gds_flag: 1
>>> bms_flag: 1
>>> nx: 185
>>> ny: 129
>>> m_value: 0.00100
>>> b_value: -NaNQ
>>> r_value: -NaNQ
>>> d_value: 3
>>> e_value: 0
>>> issue: 1123372800
>>> lead: 32400
>>> word_size: 14
>>> record_lseek_offset: 8257958
>>> data_lseek_offset: 8261037
>>> mask: 16383
>>>
>>> ===================================================
>>> Grib Record Index = 560
>>> Initialization time = 1123372800
>>> Valid time = 1123416000
>>> Accumulation time = 10800
>>> Grib Record (min, max) = (100000002004087734272.00000,
>>> -100000002004087734272.00000)
>>>
>>> _______________________________________________
>>> Met_help mailing list
>>> Met_help at mailman.ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/met_help
> _______________________________________________
> Met_help mailing list
> Met_help at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/met_help
More information about the Met_help
mailing list