[Met_help] pcp_combine, trouble reading GRIB

[matthew.pyle at noaa.gov]

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