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

Re: 20061018: Changes to CONDUIT data stream

Kevin,

Comparison of the parameters and levels  in the 0 hour NWSTG and
NCEP/CONDUIT  inital/0 hour files are the same. Both have the same 615
parameter/level/coordinates (eg, you are not missing levels etc that was
posed). 
The distinction in the PDS byte 21 as "zero hour forecasts" rather than
"uninitialized analyses" is only present in the 000 hour files only, and
therefore your 3 hour offset run is unaffected. The actual PDS 21 byte
value of "1" is correct for the data which is actually the output at the
first iterative time step of the model. The setting of this byte value
to "0" on the TG was apparently done for compatibility reasons of legacy
code.

You mentioned that you had tried modifying your code to accept a "1",
but perhaps you can try the reverse and modify this byte to "0" for the
zero hour step so that it is as your code expects?

Steve Chiswell
Unidata User Support


On Fri, 2006-10-20 at 13:15 -0500, Kevin W. Thomas wrote:
> >> Kevin,
> >>
> >> Your pqact entries are correct.
> >>
> >> I checked the NWSTG f000 hour file:
> >> SL.us008001/ST.opnl/MT.nam_CY.00/RD.20061020/fh.0000_tl.press_gr.awip3d
> >>
> >> and compared to the NCEP data file from the CONDUIT stream:
> >> data/nccf/com/nam/prod/nam.20061020/nam.t00z.awip3d00.tm00
> >>
> >> Both files are 15110520 bytes as you mentioned (size matched), however
> >> the
> >> NCEP PDS byte 21 is "1" while the NWSTG byte 21 is "0". This difference
> >> refers to
> >> an an "initialized analysis product" vs an "uninitialized analysis
> >> product".
> >> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table5.html
> >>
> >>   
> >I suspect that the size matching is a coincidence.  Although each file 
> >contains the same amount of records, the variables that corresponds to 
> >those records are totally different. Especially,  those 3D variables 
> >(geopotential height, U, V, W, QV etc.). Many vertical levels are missed 
> >in the "initialized analysis product", but the "uninitialized analysis 
> >product" contains much less variables than "initialized analysis 
> >product". That is why both products contain the same amount of records 
> >by chance.
> >
> >Yunheng Wang.
> 
> The original report was based on a 00Z ARPS and WRF runs using 00Z NAM data.
> 
> I tried doing a three hour 12Z forecast using the 12Z NAM data same result.
> 
> I then tried doing a three hour 15Z forecast using the 12Z NAM data.  This
> run uses the hour 3 and hour 6 NAM output.  The job ran with no problems.
> 
> It sounds like that NAM hour 0 files are incorrect.
> 
>       Kevin W. Thomas
>       Center for Analysis and Prediction of Storms
>       University of Oklahoma
>       Norman, Oklahoma
>       Email:  address@hidden
> >
> >> While the ruc and gfs directories have separate "anl" and "f000" files,
> >> the nam
> >> directory does not, but I don't know if that is relevant. I've sent an
> >> inquiry to NCEP 
> >> on this issue.
> >>
> >> Steve Chiswell
> >> Unidata User Support
> >>
> >>
> >>
> >> On Fri, 2006-10-20 at 10:07 -0500, Kevin W. Thomas wrote:
> >>   
> >>>> CONDUIT recipients,
> >>>>
> >>>> At 18Z, the remaining CONDUIT files (NAM, RUC, and GFS) still being
> >>>> inserted using the NWSTG naming convention will be transitioned to the
> >>>> NCEP file names:
> >>>>
> >>>> http://www.unidata.ucar.edu/data/conduit/ldm_idd/gfs_files.html
> >>>> http://www.unidata.ucar.edu/data/conduit/ldm_idd/ruc2_files.html
> >>>> http://www.unidata.ucar.edu/data/conduit/ldm_idd/nam_files.html
> >>>>
> >>>> As always, please contact address@hidden should
> >>>> you have any problems with your receipt of these products,
> >>>>
> >>>> -- 
> >>>> Steve Chiswell <address@hidden>
> >>>> Unidata
> >>>>       
> >>> There are either changes in the format of the data, or I'm doing something
> >>> wrong or both, at least for NAM data.
> >>>
> >>> First of all, here is my old "pqact.conf" entry:
> >>>
> >>> NMC2      
> >>> ^/afs/.nwstg.nws.noaa.gov/ftp/(.*)/(.*)/MT.(eta|nam)_CY.(.*)/RD.(.*)/(.*)/fh.00(.*)_tl.press_gr.awip3d
> >>>   FILE    /arpsdata2/ldm2/datafiles/eta40grb/eta40grb.\5\4f\7
> >>>
> >>> Here is my new entry:
> >>>
> >>> NMC2      ^data/nccf/com/nam/prod/nam.(.*)/nam.t(.*)z.awip3d(.*).tm00 
> >>> !(.*)!
> >>>   FILE    /arpsdata2/ldm2/datafiles/eta40grb/eta40grb.\1\2f\3
> >>>
> >>> If I use "wgrib" to determine the number of records, I get the same 
> >>> numbers
> >>> in files before and after the change.
> >>>
> >>> The first problem that I had was the software that I use (ARPS) was 
> >>> rejecting
> >>> the hour 0 data as bad.  We use a subroutine called W3FI63 that looks 
> >>> like it
> >>> had its origin in NCEP, though it looks rather old.  The documented 
> >>> variable
> >>> is something called "TIME RANGE FLAG" which seems to now be 1 for the 
> >>> initial
> >>> conditions.  It was zero before the transition.
> >>>
> >>> Okay, I change the code we use to allow that, so the initial conditions 
> >>> data
> >>> is accepted.  That program works fine.  Numerical model runs aren't fine
> >>> (ARPS and WRF).  They go unstable immediately.
> >>>
> >>> Either something is wrong with my entry above, and I'm not getting 
> >>> everything
> >>> that I did before, or something has changed.  I need help identifying 
> >>> what the
> >>> problem is, as I don't know anything about GRIB format, or what to expect 
> >>> in
> >>> the data files.
> >>>
> >>> Thanks!
> >>>
> >>>   Kevin W. Thomas
> >>>   Center for Analysis and Prediction of Storms
> >>>   University of Oklahoma
> >>>   Norman, Oklahoma
> >>>   Email:  address@hidden
-- 
Steve Chiswell <address@hidden>
Unidata