[Met_help] New MET code for processing ncdf MADIS files
John Halley Gotway
johnhg at rap.ucar.edu
Tue Mar 9 13:53:09 MST 2010
John,
OK, I took at look at your data and the config file. Here's some things
to be aware of:
(1) You definitely do have observations over your domain in the western
US. I've attached a plot showing the location of the observations. This
was generated using a little plotting utility we may include in the next
release of MET.
(2) All of the observations in the NetCDF file you sent are of type
"MSONET". So in the Point-Stat configuration file, I set:
message_type[] = [ "MSONET" ];
I don't know the MADIS format enough to know whether this is correct.
Should all the observations be that same MSONET type?
(3) I ran the following command to look at the array of temperature
observation values in the NetCDF file:
ncdump -v obs_arr obs-2006102212.nc | grep ", 11, " | more
The "11" in the output indicates that this is a temperature observation,
and the number after it tells you the pressure level for the ob. You'll
see that there aren't really on the specific levels you were choosing for
verification: P200, P300, P500, P700, P850
There just aren't any observations that occur exactly at those pressure
levels.
Instead, I tried verifying using a range of pressure levels: TMP/P200-1200
Doing that, it found 153 matched pairs. Also, if you widen the matching
time window (beg_ds and end_ds), it will find more matches.
I've attached the coinfig file I used to get the 153 matches.
(4) Lastly, I see that you'd also like to verify forecasts at the surface:
2-meter temp, 10-meter winds, and other surface vars
You should be aware the Point-Stat takes a very simplistic approach for
matching observations to surface fields - we inherited it from the NCEP
verification package we started with. It's done based solely on message
type. Observations of type "ADPSFC" and "SFCSHP" are considered by
definition to be at the surface. So the only way you'll be able to verify
surface forecasts is using observations of those types. So in your
madis2nc program, I'd suggest adding some logic to decide which
observations are at the surface and encode those as "ADPSFC".
Hope that helps.
John
> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obs-2006102212.png
Type: image/png
Size: 93587 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/met_help/attachments/20100309/3ea8f8a7/attachment-0001.png
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: point_stat-config.txt
Url: http://mailman.ucar.edu/pipermail/met_help/attachments/20100309/3ea8f8a7/attachment-0001.txt
More information about the Met_help
mailing list