[Met_help] Questions about applying thresholds in MET
John Halley Gotway
johnhg at ucar.edu
Fri Jun 11 14:51:53 MDT 2010
John,
One more piece of information. If you want to apply multiple thresholds for the wind speed, you can do so as follows:
fcst_wind_thresh[] = [ "gt2.0", "ge3.0" ];
Each threshold need to be in quotes, and they should be separated by commas.
Also, I told you that in MET we use thresholds to define contingency tables, and that is true of the fcst_thresh and obs_thresh parameters. However, the fcst_wind_thresh does behave differently -
it's really like a filtering method to filter out only those matched pairs to use in the VL1L2 computations. Perhaps we should have named it fcst_wind_filter instead to avoid the confusion.
I do realize that configuring Point-Stat (and the other MET tools) to do exactly what you want can be tricky and frustrating. There are a lot of details and options packed in there.
Hope that helps and have a good weekend.
John
John Halley Gotway wrote:
> John,
>
> Hopefully I can clear some of this up.
>
> In the MET configuration files, thresholds should be specified using the "gt, ge, lt, le, eq, ne" FORTRAN convention for specifying inequalities:
> fcst_thresh[] = [ "le5.0 gt5.0" ];
> and
> fcst_wind_thresh[] = [ "gt5.0" ];
>
> Perhaps the source of confusion is that when we write the output thresholds, we do use the more conventional notation of ">, >=, <, <=, ==, !=". Perhaps that was a poor choice and led to your
> confusion. If the documentation is misleading, please let me know where, and we can clarify it.
>
> As you are aware, in the STAT output data, there are some columns that contain threshold information: FCST_THRESH, OBS_THRESH, and COV_THRESH
> However, these columns are only used in those line types to which they apply. For instance, since continuous statistics and SL1L2 partial sums are computed over the raw fields, with generally no
> thresholding applied, the CNT and SL1L2 output line types contain "NA" in those columns. The exception to this rule is when the "fcst_wind_thresh" and "obs_wind_thresh" parameters are used. In that
> case, those thresholds are used to populate the FCST_THRESH and OBS_THRESH columns in the VL1L2 output lines.
>
> The forecast and observation thresholds do apply when computing categorical statistics - using contingency tables. You apply those thresholds to create 0/1 fields for the forecasts and observations
> and then put those counts into a contingency table and derive statistics. Therefore the FCST_THRESH and OBS_THRESH columns contain threshold values in the FHO, CTC, and CTS line types.
>
> Perhaps the confusion is what exactly we mean by "thresholding". I'm guessing you're thinking of thresholding as a process of filtering forecast and observation values and only keeping the ones that
> meet the threshold criteria. That's not really what we mean. Instead, we're keeping all the matched pairs (fcst, obs pairs) and applying the thresholds to those matched pairs to fill up a
> contingency table.
>
> I actually did uncover a bug based on this issue you sent. When I specify multiple thresholds for "fcst_wind_thresh":
> fcst_wind_thresh[] = [ "gt2.0 ge3.0" ];
> I'm only seeing output for the first threshold. I'll fix this in the code, and it'll be included in the upcoming release of METv3.0.
>
> Thanks for the reminder about MADIS data. I'll put that back on our list.
>
> Please let me know if you continue to have questions.
>
> Thanks,
> John
>
>
> John Henderson wrote:
>> Hello again John,
>>
>> The main questions I have are in regard to applying thresholds in Point
>> Stats.
>>
>> 1) There is conflicting documentation regarding whether the thresholds
>> in Point Stats should be, e.g., gt10 or >10.
>>
>> 2) Even while apparently applying thresholds using the correct syntax,
>> the Point Stat output files report only "NA" in the threshold columns.
>> This is the case for all fields (temperature, wind, moisture, etc). For
>> partial sums while computing wind direction errors, I do get part of the
>> request thresholds (see later).
>>
>> For one of my attempts, I am trying to run Point Stats to verify wind
>> speed for a) all wind speeds and then b) for all forecast/obs pairs
>> where the obs wind speeds are not identically zero. I actually have
>> forecast and obs input files with wind speeds already computed, so I
>> believe I should be applying the wind speed thresholds to grib code 32
>> and using "fcst_thresh[]" and "obs_thresh[]". For this example, I would
>> specify the two thresholds for obs_thresh as "ge0.0 gt0.0", while
>> fcst_thresh would be "ge0.0 ge0.0". However, as always, I get "NA" in
>> the output files in the threshold columns. I have verified that the
>> string "NA" only appears in my Point Stat file in the comments!
>>
>> Another use: I also compute the wind direction error statistics using
>> the wind partial sums VL1L2. Thus, to apply wind speed thresholds to
>> forecast/obs pairs in the wind direction computations, I should use the
>> variables "fcst_wind_thresh" and "obs_wind_thresh". To generate the
>> partial sums for all wind speeds, then with only non-zero obs, I use:
>>
>> fcst_wind_thresh[] = [ ">=0 >=0" ];
>> obs_wind_thresh[] = [ ">=0 >0" ];
>>
>> This, however, gives me VL1L2 output files that contain the following in
>> the fcst_thresh and obs_thresh columns:
>>
>> >=0.000 >=0.000
>>
>> I was expecting two rows, one for each threshold experiment, with the
>> fcst_thresh and obs_thresh thresholds replaced by what was requested in
>> fcst_wind_thresh and obs_wind_thresh.
>>
>> Perhaps I am completely misusing thresholds in MET. Please advise!
>>
>>
>> --
>>
>> Also, I don't think I ever heard back from you in March regarding our
>> last iteration re: getting MADIS obs in MET. I've attached our prior
>> discussions and the latest source code. In the interim, we've
>> successfully generated stats and plots in some project work at AER using
>> MET with MADIS... I'm sure you are overwhelmed with tasks right now, but
>> thought I would follow up just in case.
>>
>> John
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: New MET code for processing ncdf MADIS files
>> From:
>> John Henderson <jhenders at aer.com>
>> Date:
>> Wed, 10 Mar 2010 13:35:15 -0500
>> To:
>> John Halley Gotway <johnhg at rap.ucar.edu>
>>
>> To:
>> John Halley Gotway <johnhg at rap.ucar.edu>
>>
>>
>> John,
>>
>> We've reassigned all MSONET obs to ADPSFC and we get quite a few matches
>> (848 for TEMP and 621 each for UGRD and VGRD).
>>
>> Hopefully you'll get the same results.
>>
>> John
>>
>> On 3/9/10 3:53 PM, John Halley Gotway wrote:
>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>
More information about the Met_help
mailing list