[Met_help] New MET code for processing ncdf MADIS files
John Henderson
jhenders at aer.com
Tue Mar 9 12:29:29 MST 2010
Hi John,
OK - I've uploaded my grib file and Point-Stat config file to the
anonymous ftp directory. I have not implemented a mask.
I suppose there is a chance that the domain covered by my fairly small
grib file does not contain any mesonet obs. I admit that I have not
checked to confirm.
I look forward to seeing what you find.
Thanks.
John
On 3/9/10 2:14 PM, John Halley Gotway wrote:
> John,
>
> I haven't taken a look at the observation file yet, but I think it'd be
> easiest for me to debug this issue if you could send me all of the input
> files for Point-Stat:
> - the observation file (which you've sent).
> - the forecast file
> - the Point-Stat configuration file you're using
> - any masking Polyline you may be using in the configuration file
>
> If the forecast file is big, you can post it to our anonymous ftp site:
> ftp ftp.rap.ucar.edu
> username = anonymous
> password = "your email address"
> cd incoming/irap/met_help
> put "your files"
>
> I'll try running it through Point-Stat here and figure out why you aren't
> getting any matched pairs. It may be a problem in the madis2nc or it may
> be a problem in the configuration file.
>
> Thanks,
> John
>
>
>> John,
>>
>> We have tweaked our madis2nc code to pair up the u- and v- wind
>> components, plus convert the MADIS mesonet obs' altimeter values to
>> pressure levels. Otherwise, there are many many missing observed
>> pressure values in the mesonet files.
>>
>> However, running our new ncdf obs file through point_stat still comes up
>> with zero matches. I was wondering if anything bad with our obs file
>> (attached) is readily apparent to you. I've sliced and diced it using
>> ncdump and things seem okay, with one exception. In the header, the
>> height in meters is a float next to the lat/lon pairs (as the header
>> definition suggest), yet a dump of a separate ncdf file generated by
>> pb2nc has integer heights in the header next to the lat/lon pairs.
>>
>> Please let me know if you can take a peek at our file.
>>
>> Thanks.
>>
>> John
>>
>> On 3/4/10 3:36 PM, John Halley Gotway wrote:
>>
>>> John,
>>>
>>> Ah, yes, I see the bug in GRIB codes you describe on line 85 of
>>> madis2nc.cc:
>>> 84 const int in_windDir_gc = 31;
>>> 85 const int in_windSpeed_gc = 34;
>>>
>>> Looks like the wind direction is correct at 31, but the wind speed is
>>> wrong and should be set as:
>>> 84 const int in_windDir_gc = 31;
>>> 85 const int in_windSpeed_gc = 32;
>>>
>>> These are actually defined in a MET library:
>>> METv2.0/lib/vx_grib_classes/grib_strings.h
>>> So if this tool is compiled as part of MET, we could just use the
>>> definitions in there.
>>>
>>> Thanks,
>>> John
>>>
>>> John Henderson wrote:
>>>
>>>
>>>> Hi John,
>>>>
>>>> We noticed that the way we are applying the QC flags to wind speed and
>>>> direction may not have been correct. We're addressing that right now.
>>>> Otherwise, we noticed that the grib encoding flags for wind speed and
>>>> direction are not set according to the standard (NCEP's office note
>>>> 388). The correct ones are wind direction 031 and wind speed 032.
>>>>
>>>> As well, we're going to try to pair our wind components like you
>>>> suggested for use in VL1L2. We see in the pb-based ncdf file that the
>>>> u-
>>>> and v- components are next to each other.
>>>>
>>>> I'll provide an updated file soon - one that will address the first two
>>>> problems but likely not the pairing of wind components.
>>>>
>>>> John
>>>>
>>>> On 3/4/10 2:24 PM, John Halley Gotway wrote:
>>>>
>>>>
>>>>> John,
>>>>>
>>>>> Yes, good point about UGRD and VGRD. In Point-Stat, if you'd like to
>>>>> compute vector L1L2 partial sums (i.e. the VL1L2 line type), you'd
>>>>> need to have each UGRD observations followed by a VGRD
>>>>> observation at the same level and pointing to the same header record.
>>>>>
>>>>> For the time being, just edit the Point-Stat configuration file. In
>>>>> the fcst_field, you probably have "UGRD" followed by "VGRD" at the
>>>>> same level. For right now, just reverse their order putting
>>>>> VGRD first. That will effectively disable treating U and V as
>>>>> vectors. Here's some comments from the Point-Stat config file about
>>>>> this.
>>>>>
>>>>> // NOTE: To verify winds as vectors rather than scalars,
>>>>> // specify UGRD (or 33) followed by VGRD (or 34) with the
>>>>> // same level values.
>>>>>
>>>>> The better fix would be to modify madis2nc to list U observations at
>>>>> one level followed by V observations at the same level and pointing to
>>>>> the same header record. We imposed the convention to make
>>>>> Point-Stat run a little faster. We didn't want it wasting time
>>>>> searching through all the observations to figure out how to match up
>>>>> the U's and V's.
>>>>>
>>>>> Hope that helps,
>>>>> John
>>>>>
>>>>> John Henderson wrote:
>>>>>
>>>>>
>>>>>
>>>>>> John,
>>>>>>
>>>>>> Thanks for identifying the bug on line 885. That fixes the indexing
>>>>>> problem, however, now I get this error in point_stat:
>>>>>>
>>>>>> ...
>>>>>> Reading records for VGRD/Z010.
>>>>>> For VGRD/Z010 found 1 forecast levels and 0 climatology levels.
>>>>>>
>>>>>> ----------------------------------------
>>>>>>
>>>>>> Searching 98753 observations from 23535 PrepBufr messages.
>>>>>>
>>>>>> ERROR: process_obs_file() -> when computing vector winds, each UGRD
>>>>>> observation must be followed by a VGRD observation with the same
>>>>>> header
>>>>>> and at the same level
>>>>>>
>>>>>> Does this suggest that we're not pairing up UGRD/VGRD obs the right
>>>>>> way
>>>>>> in madis2nc?
>>>>>>
>>>>>> Regarding your seg fault, obviously we can't reproduce it. We're
>>>>>> trying
>>>>>> to think of a potential problem, but, of course, it's not easy when
>>>>>> we
>>>>>> can't reproduce the problem.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On 3/4/10 1:43 PM, John Halley Gotway wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> When I tried to run madis2nc with the sample data file you sent me,
>>>>>>> I
>>>>>>> actually got a segfault. After commenting out lines 760-761 for
>>>>>>> writing Wind Speed observations, the seg fault went away:
>>>>>>> 759 // Wind Speed
>>>>>>> 760 // write_obs_arr(f_in, nhdr, in_windSpeed_str,
>>>>>>> in_windSpeed_gc,
>>>>>>> 761 // bad_data_float, obs_arr_var, i_obs,
>>>>>>> conversion);
>>>>>>>
>>>>>>> Once I ran madis2nc successfully, I did see the error message from
>>>>>>> Point-Stat. The problem is a bug in indexing in the code I sent
>>>>>>> you.
>>>>>>> Just remove the +1 from line 885:
>>>>>>> 885 obs_arr[0] = i_hdr;
>>>>>>>
>>>>>>> The first element in the obs_arr is the index of the header
>>>>>>> information to which this observation corresponds. Point-Stat
>>>>>>> expects
>>>>>>> that that index starts at 0 and not 1, like I'd had it.
>>>>>>>
>>>>>>> Give that a shot and see if it fixes the problem.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> John Henderson wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> John,
>>>>>>>>
>>>>>>>> We've created a new file, madis2nc.cc. The new code can be compiled
>>>>>>>> inside the awips2nc directory using the attached modified Makefile.
>>>>>>>> Of
>>>>>>>> course, we'll let you decide the directory details of how the new
>>>>>>>> code
>>>>>>>> will be presented to the user community.
>>>>>>>>
>>>>>>>> Here is what the AER developer says:
>>>>>>>>
>>>>>>>> "It runs to completion for the following data types:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> acars
>>>>>>>>> acarsProfiles
>>>>>>>>> LDAD_coop
>>>>>>>>> LDAD_hydro
>>>>>>>>> maritime
>>>>>>>>> LDAD_mesonet
>>>>>>>>> metar
>>>>>>>>> sao
>>>>>>>>> LDAD_snow
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I checked that for METARS it gives the same result as awips2nc,
>>>>>>>> aside
>>>>>>>> from obs filtered out by madis2nc due to QC checks. It may need
>>>>>>>> some
>>>>>>>> more tweaking for the report type (e.g., ADPSFC, MSONET, etc) for
>>>>>>>> some
>>>>>>>> of the other data types."
>>>>>>>>
>>>>>>>> If the mesonet obs either are flagged by any QC check, or have not
>>>>>>>> been
>>>>>>>> subjected to any QC, the new code will not write them out into the
>>>>>>>> MET
>>>>>>>> ncdf output file.
>>>>>>>>
>>>>>>>> One big problem, however: The ncdf files generated by both our new
>>>>>>>> code
>>>>>>>> (madis2nc) and your old code (awips2nc) do not work in point_stats.
>>>>>>>> Perhaps the point_stats code has changed since you wrote awips2nc
>>>>>>>> or I
>>>>>>>> simply am calling things incorrectly.
>>>>>>>>
>>>>>>>> I look forward to hearing what the problem is!
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On 3/2/10 2:59 PM, John Halley Gotway wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> Thanks, I was able to retrieve the NetCDF file you sent and take a
>>>>>>>>> look at it. I was reminded of the fact that I'd written some code
>>>>>>>>> last summer to convert AWIPS point observation files into the
>>>>>>>>> NetCDF format expected by Point-Stat. But I didn't design it to
>>>>>>>>> be a
>>>>>>>>> very robust converter - just to get the job done for a particular
>>>>>>>>> NWS
>>>>>>>>> user of MET. I tried running your sample file though it,
>>>>>>>>> but it produced an error.
>>>>>>>>>
>>>>>>>>> However, I took a look at the structure of your NetCDF file
>>>>>>>>> compared
>>>>>>>>> to what the converter is trying to read, and really it's pretty
>>>>>>>>> close.
>>>>>>>>>
>>>>>>>>> I went ahead and attached the code for that tool, which I
>>>>>>>>> initially
>>>>>>>>> called "awips2nc". If you have anyone there who codes in C++, I
>>>>>>>>> think
>>>>>>>>> it'd be pretty straight-forward for them to adapt the tool to
>>>>>>>>> handle the data you're using. Perhaps this could serve as the
>>>>>>>>> starting point for a tool to ingest MADIS data directly into MET.
>>>>>>>>> Unfortunately though, we don't have time in our development
>>>>>>>>> schedule
>>>>>>>>> to work on that right now.
>>>>>>>>>
>>>>>>>>> Just copy the attached file "awips2nc_patch.tar.gz" into your
>>>>>>>>> top-level METv2.0 directory. After you untar it, you'll see a
>>>>>>>>> "src/awips2nc" directory and a new top-level Makefile named
>>>>>>>>> "Makefile_new".
>>>>>>>>> That includes lines for building the awips2nc tool. So just
>>>>>>>>> configure that Makefile to point to your local paths, and when you
>>>>>>>>> rebuild MET, it should compile awips2nc as well. If you're
>>>>>>>>> successful
>>>>>>>>> in changing that code to get it to work on your data, please send
>>>>>>>>> us
>>>>>>>>> your changes.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> John Henderson wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> John,
>>>>>>>>>>
>>>>>>>>>> I've uploaded a sample file that you have requested. The filename
>>>>>>>>>> is not
>>>>>>>>>> very informative (20061022_1000), but it is a ncdf file straight
>>>>>>>>>> from
>>>>>>>>>> the MADIS server.
>>>>>>>>>>
>>>>>>>>>> Please let me know if the line of thinking that prompted this
>>>>>>>>>> email
>>>>>>>>>> might be fruitful for our immediate needs. Otherwise, we may
>>>>>>>>>> actually
>>>>>>>>>> start to write a MADIS ncdf -> ASCII script for ingest into
>>>>>>>>>> MET. We
>>>>>>>>>> really would like to use mesonet obs in MET and I've been told
>>>>>>>>>> that
>>>>>>>>>> retrieving multiple ncdf format files from MADIS is much cleaner
>>>>>>>>>> than
>>>>>>>>>> retrieving ASCII format.
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>> On 3/1/10 3:57 PM, John Halley Gotway wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> John,
>>>>>>>>>>>
>>>>>>>>>>> Our of curiosity, I'm wondering if you could send me a sample
>>>>>>>>>>> MADIS
>>>>>>>>>>> NetCDF file that you'd like to use in MET. I'd like to see how
>>>>>>>>>>> it
>>>>>>>>>>> compares to some AWIPS point observation data we'd read in the
>>>>>>>>>>> past.
>>>>>>>>>>>
>>>>>>>>>>> You could post a sample file to our anonymous ftp site:
>>>>>>>>>>> ftp ftp.rap.ucar.edu
>>>>>>>>>>> username = anonymous
>>>>>>>>>>> password = "your email address"
>>>>>>>>>>> cd incoming/irap/met_help
>>>>>>>>>>> put "your file(s)"
>>>>>>>>>>> bye
>>>>>>>>>>>
>>>>>>>>>>> I'd appreciate it.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>> John Halley Gotway wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> John,
>>>>>>>>>>>>
>>>>>>>>>>>> I looked back through our MET-Help emails and did find another
>>>>>>>>>>>> user
>>>>>>>>>>>> going through the same process as you. And he actually sent us
>>>>>>>>>>>> some
>>>>>>>>>>>> the scripts he was using for converting MADIS to ASCII for
>>>>>>>>>>>> surface observations. I wanted to pass them along to you in
>>>>>>>>>>>> case
>>>>>>>>>>>> they're of use. However I think he was starting with an ASCII
>>>>>>>>>>>> version of MADIS data instead of NetCDF.
>>>>>>>>>>>>
>>>>>>>>>>>> His scripts are attached.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Subject: MADIS_ASCII2NC scripts/files
>>>>>>>>>>>> Date: Wed, 4 Mar 2009 12:49:06 -0600
>>>>>>>>>>>> From: Case, Jonathan
>>>>>>>>>>>> (MSFC-VP61)[Other]<jonathan.case-1 at nasa.gov>
>>>>>>>>>>>> To: John Halley Gotway<johnhg at rap.ucar.edu>
>>>>>>>>>>>> References:<A9BB815E34BC6947A9DF9EABB15F147101B5EB18 at NDMSEVS31A.ndc.nasa.gov>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <53403.128.117.65.62.1236126600.squirrel at mail.rap.ucar.edu>
>>>>>>>>>>>> <A9BB815E34BC6947A9DF9EABB15F147101B5EB5F at NDMSEVS31A.ndc.nasa.gov>
>>>>>>>>>>>> <49AEA2B6.7080403 at rap.ucar.edu>
>>>>>>>>>>>>
>>>>>>>>>>>> John,
>>>>>>>>>>>>
>>>>>>>>>>>> I've bundled up a bunch of scripts/files I used to re-format
>>>>>>>>>>>> and
>>>>>>>>>>>> process
>>>>>>>>>>>> the MADIS sfc observations for ascii2nc. The file is attached
>>>>>>>>>>>> to
>>>>>>>>>>>> this
>>>>>>>>>>>> email.
>>>>>>>>>>>>
>>>>>>>>>>>> Please keep in mind that these scripts were just written
>>>>>>>>>>>> (except for
>>>>>>>>>>>> dayadd, which I've used in many other scripts), so it's still
>>>>>>>>>>>> "drafty".
>>>>>>>>>>>> Also, it's only set up to work on sfc observations only, not
>>>>>>>>>>>> any
>>>>>>>>>>>> upper-air data yet.
>>>>>>>>>>>>
>>>>>>>>>>>> Take care,
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> John,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, of course, reformatting into the catch-all ASCII format
>>>>>>>>>>>>> seems
>>>>>>>>>>>>> like
>>>>>>>>>>>>> the best start. Thanks for reminding me about that option.
>>>>>>>>>>>>> Will
>>>>>>>>>>>>> let you
>>>>>>>>>>>>> know how the MADIS->ASCII script works if I choose to jump
>>>>>>>>>>>>> into the
>>>>>>>>>>>>> task!
>>>>>>>>>>>>>
>>>>>>>>>>>>> John
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/26/10 1:38 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can tell you that unfortunately it won't be as simple as
>>>>>>>>>>>>>> renaming
>>>>>>>>>>>>>> some variables. You know, rather than modifying the NetCDF
>>>>>>>>>>>>>> file
>>>>>>>>>>>>>> directly and trying to figure out the details of what the
>>>>>>>>>>>>>> PB2NC
>>>>>>>>>>>>>> output looks like, I'd suggest using an intermediate ASCII
>>>>>>>>>>>>>> file.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It'd probably be easiest to parse the MADIS observations and
>>>>>>>>>>>>>> dump
>>>>>>>>>>>>>> them
>>>>>>>>>>>>>> out in the ASCII format that the ASCII2NC tool can read.
>>>>>>>>>>>>>> Then run
>>>>>>>>>>>>>> them through ASCII2NC and use them in Point-Stat. I know
>>>>>>>>>>>>>> that's a lot of steps, but I do think it'd be the most
>>>>>>>>>>>>>> straight-forward way to go.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You can find details of what the supported ASCII format in
>>>>>>>>>>>>>> the MET
>>>>>>>>>>>>>> User's Guide:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.dtcenter.org/met/users/docs/users_guide/MET_Users_Guide_v2.0_rev2.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Keep us posted on know how it goes. And if you're MADIS ->
>>>>>>>>>>>>>> ASCII
>>>>>>>>>>>>>> script works well, we'd be happy to post it on the MET
>>>>>>>>>>>>>> website for
>>>>>>>>>>>>>> other users.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for your quick response.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would anyone be able to provide some basic details (e.g.,
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>> PB2NC
>>>>>>>>>>>>>>> fields are required) of the PB2NC ncdf files to help guide
>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> trying to match up the MADIS ncdf and PB2NC ncdf files?
>>>>>>>>>>>>>>> Perhaps
>>>>>>>>>>>>>>> it's a
>>>>>>>>>>>>>>> simple as a renaming of a field or two...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/26/10 12:34 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, the file formats are different, but I have never
>>>>>>>>>>>>>>>> worked
>>>>>>>>>>>>>>>> directly
>>>>>>>>>>>>>>>> with MADIS data myself. I imagine you'd need to reformat
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> MADIS
>>>>>>>>>>>>>>>> observations to make them look like the NetCDF output of
>>>>>>>>>>>>>>>> PB2NC. There have been other MET users who would like to
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> MADIS
>>>>>>>>>>>>>>>> observations, but we haven't had time to add direct support
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> use in MET.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'll forward your request to others in our group to see
>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>> we can
>>>>>>>>>>>>>>>> put it in our development timeline.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello again John,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks again for your previous help.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Perhaps you could also save me a little time by explaining
>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>> MADIS
>>>>>>>>>>>>>>>>> data can be easily (or not so easily) used in WRF-MET.
>>>>>>>>>>>>>>>>> Specifically, is
>>>>>>>>>>>>>>>>> the ncdf file format generated by pb2nc different from
>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>> might be
>>>>>>>>>>>>>>>>> expected in, say, a MADIS mesonet ncdf file?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 1/7/10 2:39 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Unfortunately, no. The PB2NC tool is not set up to
>>>>>>>>>>>>>>>>>> extract
>>>>>>>>>>>>>>>>>> precipitation observations from PREPBUFR files. It's
>>>>>>>>>>>>>>>>>> only set
>>>>>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>>>>>> extract observations of Pressure, Specific Humidity,
>>>>>>>>>>>>>>>>>> Temperature,
>>>>>>>>>>>>>>>>>> Height, and U/V-components of wind.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For verification of QPF, you'll either need to use a
>>>>>>>>>>>>>>>>>> gridded
>>>>>>>>>>>>>>>>>> analysis,
>>>>>>>>>>>>>>>>>> like StageII/IV
>>>>>>>>>>>>>>>>>> (http://www.emc.ncep.noaa.gov/mmb/ylin/pcpanl/stage2
>>>>>>>>>>>>>>>>>> and http://www.emc.ncep.noaa.gov/mmb/ylin/pcpanl/stage4)
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> reformat ASCII versions of gauge data using the ASCII2NC
>>>>>>>>>>>>>>>>>> tool
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> point verification.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've done both of these.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We would like to expand our support for the observation
>>>>>>>>>>>>>>>>>> types
>>>>>>>>>>>>>>>>>> packed
>>>>>>>>>>>>>>>>>> into the PREPBUFR files, but right now I'm really not
>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>> is/is
>>>>>>>>>>>>>>>>>> not in there.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Oh, okay. Just thought I'd point it out! Thanks for
>>>>>>>>>>>>>>>>>>> explaining...
>>>>>>>>>>>>>>>>>>> Unfortunately, right at the moment I don't have any long
>>>>>>>>>>>>>>>>>>> (>99-h)
>>>>>>>>>>>>>>>>>>> forecast fields handy to investigate my concerns
>>>>>>>>>>>>>>>>>>> directly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There is one other somewhat-related item you might be
>>>>>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>> help me
>>>>>>>>>>>>>>>>>>> out with. I'm having trouble finding precipitation in
>>>>>>>>>>>>>>>>>>> pb2nc-generated
>>>>>>>>>>>>>>>>>>> netcdf files. I've converted a number of PrepBufr obs
>>>>>>>>>>>>>>>>>>> files but
>>>>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>>>>> find a grib code that should contain precip. Do you have
>>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>> experience
>>>>>>>>>>>>>>>>>>> working with precip in PrepBufr format?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 1/7/10 2:14 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No those "HH" arguments to PCP-Combine should be fine.
>>>>>>>>>>>>>>>>>>>> Perhaps
>>>>>>>>>>>>>>>>>>>> listing the HH as 2-digits is misleading, but it'll
>>>>>>>>>>>>>>>>>>>> read the
>>>>>>>>>>>>>>>>>>>> integer
>>>>>>>>>>>>>>>>>>>> number of hours (any number of digits) and handle them
>>>>>>>>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To make sure, I ran PCP-Combine on some that that
>>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>>> accumulations intervals> 100 hours. All three
>>>>>>>>>>>>>>>>>>>> commands
>>>>>>>>>>>>>>>>>>>> (sum, add,
>>>>>>>>>>>>>>>>>>>> and subtract) worked fine even when the accumulation
>>>>>>>>>>>>>>>>>>>> interval on
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> command line was> 100.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please let me know if anything else comes up.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hello again John,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regarding the> 99-h forecast lead time
>>>>>>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>> couple of
>>>>>>>>>>>>>>>>>>>>> weeks
>>>>>>>>>>>>>>>>>>>>> ago... I believe that PCP_COMBINE will also need to be
>>>>>>>>>>>>>>>>>>>>> modified
>>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>> there is an argument to the code that is of the format
>>>>>>>>>>>>>>>>>>>>> HH
>>>>>>>>>>>>>>>>>>>>> (for the
>>>>>>>>>>>>>>>>>>>>> 'sum'
>>>>>>>>>>>>>>>>>>>>> option: out_accum).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Please let me know if this is actually the case.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> John Henderson
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12/23/09 5:46 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I checked and found out that this really is a problem
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> STAT-Analysis and MODE-Analysis tools. When I ran
>>>>>>>>>>>>>>>>>>>>>> STAT-Analysis
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> specified a lead time of "-fcst_lead 114", it errored
>>>>>>>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>>>>>>> with an
>>>>>>>>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>>>>>>>> message about not being able to parse that time.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So I modified the library code which parses these
>>>>>>>>>>>>>>>>>>>>>> strings to
>>>>>>>>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> lead hours to be either 2 or 3 digits long.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I've posted the fix to:
>>>>>>>>>>>>>>>>>>>>>> http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks for pointing out this problem, and please let
>>>>>>>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>> if you
>>>>>>>>>>>>>>>>>>>>>> uncover any more issues.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the clarification of everything.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I'll let you know if I uncover any other problems
>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> triple-digit
>>>>>>>>>>>>>>>>>>>>>>> lead
>>>>>>>>>>>>>>>>>>>>>>> times, but, otherwise, I'll await your fix.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the quick responses!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 12/23/09 4:37 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Regarding WPP, I really don't think that you'll
>>>>>>>>>>>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>>>> currently working on a project with folks from NOAA
>>>>>>>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>>>>> we're
>>>>>>>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>>>>>>> forecasts out to 114 hours and are running the most
>>>>>>>>>>>>>>>>>>>>>>>> recently
>>>>>>>>>>>>>>>>>>>>>>>> released
>>>>>>>>>>>>>>>>>>>>>>>> version of WPP just fine. You would only
>>>>>>>>>>>>>>>>>>>>>>>> potentially
>>>>>>>>>>>>>>>>>>>>>>>> have an
>>>>>>>>>>>>>>>>>>>>>>>> issue if
>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>> were running your forecasts out> 255
>>>>>>>>>>>>>>>>>>>>>>>> hours.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Regarding issues with MET, you're probably correct.
>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>> come up in your use of the MODE-Analysis and
>>>>>>>>>>>>>>>>>>>>>>>> STAT-Analysis
>>>>>>>>>>>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>>>>>>>>>>>>> That's
>>>>>>>>>>>>>>>>>>>>>>>> the place you'd be specifying the forecast lead
>>>>>>>>>>>>>>>>>>>>>>>> time in
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> config
>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> on the command line. I believe it
>>>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>>>>>>>>> easy fix
>>>>>>>>>>>>>>>>>>>>>>>> involving
>>>>>>>>>>>>>>>>>>>>>>>> changes to the "timestring_to_sec" routine in the
>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>> METv2.0/lib/vx_cal/time_strings.cc.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> However, before making any changes, I'd like to do
>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>> testing to
>>>>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>> sure it really is a problem. And once I verify
>>>>>>>>>>>>>>>>>>>>>>>> that,
>>>>>>>>>>>>>>>>>>>>>>>> I'll work
>>>>>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>>>>>> fix.
>>>>>>>>>>>>>>>>>>>>>>>> If I isolate the problem and come up with a fix,
>>>>>>>>>>>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>>>>>>>>>>>> post
>>>>>>>>>>>>>>>>>>>>>>>> it to
>>>>>>>>>>>>>>>>>>>>>>>> the MET
>>>>>>>>>>>>>>>>>>>>>>>> website and update the package of bug fixes.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'll let you know how it pans out. Please let me
>>>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>>>> if, in
>>>>>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>> MET, you find another place where it's a problem to
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> forecast
>>>>>>>>>>>>>>>>>>>>>>>> hours>
>>>>>>>>>>>>>>>>>>>>>>>> 99.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hello John,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the prompt response. Perhaps I had
>>>>>>>>>>>>>>>>>>>>>>>>> briefly
>>>>>>>>>>>>>>>>>>>>>>>>> come
>>>>>>>>>>>>>>>>>>>>>>>>> across
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> WPP email and thought it was actually related to
>>>>>>>>>>>>>>>>>>>>>>>>> MET...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I believe - according to the user manual - that
>>>>>>>>>>>>>>>>>>>>>>>>> MET
>>>>>>>>>>>>>>>>>>>>>>>>> allows the
>>>>>>>>>>>>>>>>>>>>>>>>> user to
>>>>>>>>>>>>>>>>>>>>>>>>> specify forecast lead time as HH[MMSS], which
>>>>>>>>>>>>>>>>>>>>>>>>> seems to
>>>>>>>>>>>>>>>>>>>>>>>>> me to
>>>>>>>>>>>>>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>>>>>>>>> leads times> 99h. Am I mistaken?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Regarding WPP...I intend to verify precip
>>>>>>>>>>>>>>>>>>>>>>>>> accumulation
>>>>>>>>>>>>>>>>>>>>>>>>> in MET
>>>>>>>>>>>>>>>>>>>>>>>>> for a
>>>>>>>>>>>>>>>>>>>>>>>>> year-long series of 5.5-day forecasts that overlap
>>>>>>>>>>>>>>>>>>>>>>>>> at the
>>>>>>>>>>>>>>>>>>>>>>>>> beginning of
>>>>>>>>>>>>>>>>>>>>>>>>> each forecast run to avoid spin-up problems. It's
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>>>>>>>>>> standard
>>>>>>>>>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>>>>>>>>> of generating year-long WRF simulations. However,
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>> be applying WPP to WRF forecasts with forecast
>>>>>>>>>>>>>>>>>>>>>>>>> lead
>>>>>>>>>>>>>>>>>>>>>>>>> times
>>>>>>>>>>>>>>>>>>>>>>>>> of 12
>>>>>>>>>>>>>>>>>>>>>>>>> h to
>>>>>>>>>>>>>>>>>>>>>>>>> 132
>>>>>>>>>>>>>>>>>>>>>>>>> h. I hadn't anticipated any problems with WPP,
>>>>>>>>>>>>>>>>>>>>>>>>> unfortunately. I
>>>>>>>>>>>>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>>>>>>>> vague memory that someone had come up with a fix
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> long-lead
>>>>>>>>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>>>>>>> problem, but I'm not sure. Would you be able to
>>>>>>>>>>>>>>>>>>>>>>>>> investigate
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> status
>>>>>>>>>>>>>>>>>>>>>>>>> for me?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 12/23/09 2:51 PM, John Halley Gotway wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I looked back through the old MET-Help emails and
>>>>>>>>>>>>>>>>>>>>>>>>>> couldn't
>>>>>>>>>>>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>>>>>>>>>>> anything
>>>>>>>>>>>>>>>>>>>>>>>>>> that would explain a problem of using fcst_lead>=
>>>>>>>>>>>>>>>>>>>>>>>>>> 100
>>>>>>>>>>>>>>>>>>>>>>>>>> hours. So
>>>>>>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>> aware of a problem with that. I did find one
>>>>>>>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>>>>>>>> related to this but I believe that was due to an
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrectly
>>>>>>>>>>>>>>>>>>>>>>>>>> packed
>>>>>>>>>>>>>>>>>>>>>>>>>> GRIB
>>>>>>>>>>>>>>>>>>>>>>>>>> file, not a problem in MET itself.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> However, there are some issues in WPP
>>>>>>>>>>>>>>>>>>>>>>>>>> (WRF-PostProcessor) for
>>>>>>>>>>>>>>>>>>>>>>>>>> accumulated precip when the forecast lead time
>>>>>>>>>>>>>>>>>>>>>>>>>> extends
>>>>>>>>>>>>>>>>>>>>>>>>>> beyond 255
>>>>>>>>>>>>>>>>>>>>>>>>>> hours.
>>>>>>>>>>>>>>>>>>>>>>>>>> The time value of 255+ overflows the
>>>>>>>>>>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>>>>>>>> byte
>>>>>>>>>>>>>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>>>>>>>>>>>>>> allocated in the GRIB record to store that time
>>>>>>>>>>>>>>>>>>>>>>>>>> info.
>>>>>>>>>>>>>>>>>>>>>>>>>> This is
>>>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> issue for accumulated precip since you have to
>>>>>>>>>>>>>>>>>>>>>>>>>> store 2
>>>>>>>>>>>>>>>>>>>>>>>>>> times
>>>>>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>>>>> GRIB
>>>>>>>>>>>>>>>>>>>>>>>>>> record - accumulation starting and ending times.
>>>>>>>>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>>>>>>>>> not sure of the status of this issue, but if you
>>>>>>>>>>>>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>>>>>>>>>>>>> across it,
>>>>>>>>>>>>>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>>>>>>>>>>>>>> look into it more.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I'd say, proceed with trying to use MET to verify
>>>>>>>>>>>>>>>>>>>>>>>>>> forecasts>= 100
>>>>>>>>>>>>>>>>>>>>>>>>>> hours.
>>>>>>>>>>>>>>>>>>>>>>>>>> And if you run into any problems,
>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>> let
>>>>>>>>>>>>>>>>>>>>>>>>>> us know
>>>>>>>>>>>>>>>>>>>>>>>>>> through
>>>>>>>>>>>>>>>>>>>>>>>>>> met_help at ucar.edu.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If you haven't already done so, I would suggest
>>>>>>>>>>>>>>>>>>>>>>>>>> retrieving
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>>>>>>>>>>>> set of bug fixes for METv2.0 from:
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.dtcenter.org/met/users/support/known_issues/METv2.0/index.php
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Hope that helps,
>>>>>>>>>>>>>>>>>>>>>>>>>> John Halley Gotway
>>>>>>>>>>>>>>>>>>>>>>>>>> johnhg at ucar.edu
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> John Henderson wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> When first I installed WRF-MET I believe I saw a
>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>>>>>>> somewhere
>>>>>>>>>>>>>>>>>>>>>>>>>>> about how to apply WRF-MET to forecasts that
>>>>>>>>>>>>>>>>>>>>>>>>>>> require a
>>>>>>>>>>>>>>>>>>>>>>>>>>> fcst_lead of
>>>>>>>>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>>>>>>>>> least 100 h, however, I can't seem to find it
>>>>>>>>>>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Can
>>>>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>>>>> point me
>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>> the right direction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> John Henderson
>>>>>>>>>>>>>>>>>>>>>>>>>>> AER, Inc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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