[conduit] NAM

To add to the discussions on the WRF / Gembud / Conduit lists about recent NAM issues, the 12z NAM218 run coming over NOAAPort had some serious issues that I haven't figured out quite yet.  Note here:

http://modelweather.com/files/cases/2017/03/2017.03.23.12knam.png

that is a screenshot of my 12knam directory... notice that the 06z run came through just fine, and all of my products ran... however, with the 12z run, notice that everything "seems" to have been encoded within one forecast hour (F021)... I'm not quite sure how the data would happen to fit within one forecast hour... it seems strange 

I'll run a notifyme and hopefully catch any changes on the next run unless someone has already done that and has a pqact handy?  

cheers,

--patrick

…………………………………………………………...........

Patrick L. Francis

Director of Research & Development

Aeris Weather

 

http://aerisweather.com/

http://modelweather.com/

address@hidden 

http://facebook.com/wxprofessor/

 

…………………………………………………………

..

 

------ Original Message ------

From: "Eric Rogers - NOAA Federal" <address@hidden>

To: "Rebecca Cosgrove - NOAA Federal" <address@hidden>

Cc: "Steven Earle" <address@hidden>; "address@hidden" <address@hidden>; "Dataflow Team" <address@hidden>; "Wojciech Cencek - NOAA Affiliate" <address@hidden>

Sent: 3/22/2017 11:11:30 PM

Subject: Re: [conduit] Unable to initialize WRF using NAM212 (awip3d) since the upgrade on 3/21

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 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 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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: address@hidden
Phone: 518-442-4578                            
_____________________________________________

---

From: address@hidden.edu <address@hidden.edu> on behalf of Mike Leuthold <address@hidden>
Sent: Wednesday, March 22, 2017 6:03:07 PM
To: address@hidden
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 (cell)
520-621-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
address@hidden
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
address@hidden
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
address@hidden
For list information or to unsubscribe, visit: 
http://www.unidata.ucar.edu/mailing_lists/