Hello,
I've done an early look:
1) I took the GRIB2 awip3d36 file from the 12z 3/22 run and ran an
inventory, I saw no bad values
2) When I converted the GRIB2 awip3d36 to GRIB1 using a circa 2013 version
of cnvgrib, I got a bad 700 mb height number
rec 316:9492050:date 2017032218 <(201)%20703-2218> HGT kpds5=7 kpds6=100
kpds7=700 levels=(2,188) grid=255 700 mb 36hr fcst:
HGT=Geopotential height [gpm]
timerange 0 P1 36 P2 0 TimeU 1 nx 185 ny 129 GDS grid 3 num_in_ave 0
missing 0
center 7 subcenter 0 process 84 Table 2 scan: WE:SN winds(grid)
Lambert Conf: Lat1 12.190000 Lon1 226.541000 Lov 265.000000
Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
North Pole (185 x 129) Dx 40.635000 Dy 40.635000 scan 64 mode 136
min/max data -1.25181e+07 3176.45 num bits 24 BDS_Ref -1.25181e+10
DecScale 3 BinScale 10
3) When I used a current cnvgrib compiled with our latest version of g2
lib, the bad height value went away
rec 316:9492050:date 2017032218 <(201)%20703-2218> HGT kpds5=7 kpds6=100
kpds7=700 levels=(2,188) grid=255 700 mb 36hr fcst:
HGT=Geopotential height [gpm]
timerange 0 P1 36 P2 0 TimeU 1 nx 185 ny 129 GDS grid 3 num_in_ave 0
missing 0
center 7 subcenter 0 process 84 Table 2 scan: WE:SN winds(grid)
Lambert Conf: Lat1 12.190000 Lon1 226.541000 Lov 265.000000
Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
North Pole (185 x 129) Dx 40.635000 Dy 40.635000 scan 64 mode 136
min/max data 2653.82 3192.7 num bits 16 BDS_Ref 2.65382e+06 DecScale 3
BinScale 4
I assume the code that failed (WRF Real) is a Fortran code as I recall from
my WRF days, and that it reads GRIB2. If so, my questions for the CONDUIT
people are):1) does it use NCEP libraries (specifically the GRIB2 (g2)
library, 2) If so, how old is this library? 3) If you use g2lib and if I
provided a modified routine, could it be tested?
We run the NEMS NPS code which is very similar to the WRF Real code, and in
NAMv4, I had to ensure that I compiled it with our latest version of g2 lib
which had a modified routine that fixed problems I encountered when
unpacking complex-packed GRIB2 files. The random nature of this error makes
me think this is the problem. Smaller grids are more suspectible to the
error, whicgh is probably why you don;t see it in the larger awip32 North
American domain files.
Some background: in the new NAM we output GRIB2 direct from the
post-processing, in the old NAM all GRB2 files were converted from GRIB1
with jpeg2000 compression. We switched the new NAM GRIB2 to use complex
packing because it is faster and it allowed us not to exceed the NAM
product delivery window.
Take care
Eric
On Wed, Mar 22, 2017 at 10:05 PM, Rebecca Cosgrove - NOAA Federal <
rebecca.cosgrove@xxxxxxxx> wrote:
> Sorry -- should have read the entire thread. Mike confirmed in another
> email that he pulled down the awip3d 40km file and it also seemed to have
> the corruption.
>
> I'll pull in some other folks now.
>
> Eric, Wojciech -- some of our users are noting issues with the 40km NAM
> files since the upgrade. Can you please take a look?
>
> Thanks.
> Becky
>
> On Wed, Mar 22, 2017 at 10:01 PM, Rebecca Cosgrove - NOAA Federal <
> rebecca.cosgrove@xxxxxxxx> wrote:
>
>> Hi Folks.
>> Let's try something. I want to see if it's the 40km grids themselves, or
>> something about the way we're breaking them up to insert into the LDM for
>> CONDUIT.
>>
>> Dataflow -- can you tell us the equivalent files on ftpprd to the 40km
>> ones we send to CONDUIT?
>>
>> Then if one of you on this thread can pull down that full file from our
>> ftp server and see if you get the same corruption we'll know which avenue
>> to go down in our troubleshooting. I want to make sure it's not our
>> breaking up of the file before I bring in the model developer.
>>
>> More to come in the morning.
>> Becky
>>
>> On Wed, Mar 22, 2017 at 9:06 PM, Tyle, Kevin R <ktyle@xxxxxxxxxx> wrote:
>>
>>> Mike, I am seeing the exact same error as you with the 40 km NAM grids
>>> since the upgrade.
>>>
>>>
>>> _____________________________________________
>>> Kevin Tyle, Manager of Departmental Computing
>>> Dept. of Atmospheric & Environmental Sciences
>>> University at Albany
>>> Earth Science 235, 1400 Washington Avenue
>>> Albany, NY 12222
>>> Email: ktyle@xxxxxxxxxx
>>> Phone: 518-442-4578 <(518)%20442-4578>
>>> _____________________________________________
>>> ------------------------------
>>> *From:* conduit-bounces@xxxxxxxxxxxxxxxx <conduit-bounces@xxxxxxxxxxxx.
>>> edu> on behalf of Mike Leuthold <leuthold@xxxxxxxxxxxxxxxx>
>>> *Sent:* Wednesday, March 22, 2017 6:03:07 PM
>>> *To:* conduit@xxxxxxxxxxxxxxxx
>>> *Subject:* [conduit] Unable to initialize WRF using NAM212 (awip3d)
>>> since the upgrade on 3/21
>>>
>>> I am getting an error with real.exe in seemingly random times. I don't
>>> actually think it's a CONDUIT problem as I downloaded the awip3d
>>> directly and get the same problem.
>>>
>>> Domain 1: Current date being processed: 2017-03-24_06:00:00.0000, which
>>> is loop # 13 out of 29
>>> configflags%julyr, %julday, %gmt: 2017 83 6.000000
>>> metgrid input_wrf.F first_date_input = 2017-03-24_06:00:00
>>> metgrid input_wrf.F first_date_nml = 2017-03-22_18:00:00
>>> Ignoring all time series locations beyond # 1. Increase max_ts_locs in
>>> namelist.input
>>> Timing for input 1 s.
>>> flag_soil_layers read from met_em file is 1
>>> Using sfcprs3 to compute psfc
>>> i,j = 515 114
>>> target pressure and value = 11.06958 -2.457370
>>> column of pressure and value = 11.49449 0.0000000E+00
>>> column of pressure and value = 11.47927 128.0209
>>> column of pressure and value = 11.45342 346.5604
>>> column of pressure and value = 11.42688 569.4280
>>> column of pressure and value = 11.39957 796.8333
>>> column of pressure and value = 11.37142 1029.564
>>> column of pressure and value = 11.34235 1269.082
>>> column of pressure and value = 11.31232 1515.348
>>> column of pressure and value = 11.28131 1769.324
>>> column of pressure and value = 11.24930 2031.577
>>> column of pressure and value = 11.21623 2302.089
>>> column of pressure and value = 11.18206 2580.684
>>> column of pressure and value = 11.14673 2867.329
>>> column of pressure and value = NaN -2202740.
>>> column of pressure and value = 8.517193 20560.38
>>> -------------- FATAL CALLED ---------------
>>> FATAL CALLED FROM FILE: <stdin> LINE: 5108
>>> troubles, could not find trapping x locations
>>>
>>> I think this is a corruption of only the 40km grids as I manually
>>> downloaded the 32km awip32 grids from the same time and it did work.
>>> Unfortunately, the 32km is not available on CONDUIT and I'd MUCH prefer
>>> using CONDUIT NAM grids rather than downloading from NCEP. Anyone have
>>> any ideas?
>>> thanks.
>>> Mike
>>>
>>>
>>>
>>> --
>>> Mike Leuthold
>>> Manager, Regional Weather Modeling Program
>>> University of Arizona, Atmospheric Sciences
>>> 520-282-1478 <(520)%20282-1478> (cell)
>>> 520-621-2863 <(520)%20621-2863> (office)
>>>
>>> _______________________________________________
>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>> recorded in the Unidata inquiry tracking system and made publicly
>>> available through the web. Users who post to any of the lists we
>>> maintain are reminded to remove any personal information that they
>>> do not want to be made public.
>>>
>>>
>>> conduit mailing list
>>> conduit@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>> _______________________________________________
>>> NOTE: All exchanges posted to Unidata maintained email lists are
>>> recorded in the Unidata inquiry tracking system and made publicly
>>> available through the web. Users who post to any of the lists we
>>> maintain are reminded to remove any personal information that they
>>> do not want to be made public.
>>>
>>>
>>> conduit mailing list
>>> conduit@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>
>>
>
