[Met_help] [rt.rap.ucar.edu #58608] History for leadtime-in-METv4.0
John Halley Gotway via RT
met_help at ucar.edu
Wed Oct 10 09:40:48 MDT 2012
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Dear John,
Thank you for redirecting my questions to Paul, I got the answer.
Could you help me with other two things for which I did not find suffucient explanation in the User's Guide?
1. There was a lead time parameter in METv3.1 point_stat tool efficient for our ONE variable forecast grib-1 files with records consecutively corresponding to fields of analysis (zero lead), 1hr fcst, 2hr fcst, etc.
We retained this file structure for the grib-2 format of the COSMO model output. But our final statistical METv.4 tables indicate a constant forecast date for all records as if the forecast time is not calculated from the grib-2 tables.
In the MET demonstration examples, the 'valid fcst time' was one for all records in a particular forecast data file with multiple variables. No need of any extra lead time definition.
Certainly, I can extract fcst records with the 'valid time' I need for the verification against observations given. But maybe there is some other way to point at the lead time for the file organized in our manner without additional records' scattering?
2. I applied simple MET internal graphics of plot_point_obs tool to solve these problems with the grid definition. But there are no hints of how to use plot_data_plane. May I ask you to send me an example or the list of options for this additional MET tool?
Thank you in advance,
best regards,
Anatoly
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #58608] leadtime-in-METv4.0
From: John Halley Gotway
Time: Mon Oct 08 07:58:44 2012
Anatoly,
I'll answer your second question first...
I've created a task in our issue tracking system to update the MET
User's Guide and MET Online Tutorial to include information about the
optional plot_point_obs and plot_data_plane utility tools. To
see the usage statement for plot_data_plane, just call it with no
arguments:
[johnhg at rambler]% ./plot_data_plane
*** Model Evaluation Tools (METV4.0) ***
Usage: plot_data_plane
input_filename
output_filename
config_string
[-color_table color_table_name]
[-plot_range min max]
[-title title_string]
[-log file]
[-v level]
where "input_filename" is the name of a gridded data file to be
plotted (required).
"output_filename" is the name of the output PostScript
file to be written (required).
"config_string" defines the data to be plotted from the
input file (required).
"-color_table color_table_name" overrides the default
color table ("$(MET_BASE_DIR)/data/colortables/met_default.ctable")
(optional).
"-plot_range min max" defines the range of the data to be
plotted (optional).
"-title title_string" specifies the plot title string
(optional).
"-log file" outputs log messages to the specified file
(optional).
"-v level" overrides the default level of logging (2)
(optional).
Here's an example of running it using some test data included with
MET:
METv4.0/bin/plot_data_plane \
METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
test.ps \
'name="TMP"; level="Z2";'
The tricky part is often the last entry, the "config_string". This is
the information used to select out a 2D slice of data from the input
file. You specify this in exactly the same way you specify
data in the "field" entry in the PointStatConfig file. Usually, you
can just list the "name" and "level" you want, but if there are
multiple fields that match that description, you can provide more
filtering information. Look in METv4.0/data/config/README for more
info.
For example, if you want to specify the record that has a particular
lead time, you'd use this config_string:
'name="TMP"; level="Z2"; lead_time="12";'
Now run the same command but using a lead time not contained in that
sample file:
'name="TMP"; level="Z2"; lead_time="15";'
You should get this error message:
ERROR :
ERROR : plot_data_plane -> trouble getting field "name="TMP";
level="Z2"; lead_time="15";" from file
"METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212"
ERROR :
I'm a little unclear on the issue you're describing in your first
question.
Could you please send me an example of MET input/output that
demonstrates the issue?
www.dtcenter.org/met/users/support/met_help.php#ftp
All of the STAT output files include common header columns that
contain, among other things, timing information. For each field
that's evaluated, that includes the forecast lead and valid times.
Those times should correspond to the times defined in the data you're
verifying. We also include timing information for the observations in
case you want to verifying a forecast at one time against
observations at another. But are you saying that when verifying GRIB2
data, the times in the MET output do not correspond to the times in
the GRIB2 files?
Thanks,
John
On 10/08/2012 03:26 AM, muravev at mecom.ru via RT wrote:
>
> Mon Oct 08 03:26:13 2012: Request 58608 was acted upon.
> Transaction: Ticket created by muravev at mecom.ru
> Queue: met_help
> Subject: leadtime-in-METv4.0
> Owner: Nobody
> Requestors: muravev at mecom.ru
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>
>
> Dear John,
>
> Thank you for redirecting my questions to Paul, I got the answer.
>
> Could you help me with other two things for which I did not find
suffucient explanation in the User's Guide?
>
> 1. There was a lead time parameter in METv3.1 point_stat tool
efficient for our ONE variable forecast grib-1 files with records
consecutively corresponding to fields of analysis (zero lead), 1hr
fcst, 2hr fcst, etc.
>
> We retained this file structure for the grib-2 format of the COSMO
model output. But our final statistical METv.4 tables indicate a
constant forecast date for all records as if the forecast time is not
calculated from the grib-2 tables.
>
> In the MET demonstration examples, the 'valid fcst time' was one for
all records in a particular forecast data file with multiple
variables. No need of any extra lead time definition.
>
> Certainly, I can extract fcst records with the 'valid time' I need
for the verification against observations given. But maybe there is
some other way to point at the lead time for the file organized in our
manner without additional records' scattering?
>
> 2. I applied simple MET internal graphics of plot_point_obs tool to
solve these problems with the grid definition. But there are no hints
of how to use plot_data_plane. May I ask you to send me an example or
the list of options for this additional MET tool?
>
>
> Thank you in advance,
> best regards,
>
> Anatoly
>
>
>
------------------------------------------------
Subject: leadtime-in-METv4.0
From: muravev at mecom.ru
Time: Tue Oct 09 06:03:23 2012
Dear John,
Thank you very much for your explanation for the plot_data_plane tool.
What I was interested in was just the 'tricky part', now I see how it
works.
Again, my principal question was about the lead time definition in the
comand-line of the point_stat tool. In the model test files
Sochi2_T_2M.grb1/grb2 the only variable TMP at Z2 with 43 hourly
records corresponding to lead-time intervals is given, where rec-1 is
2012080100 analysis field, rec-2 is 2012080101 fcst field etc.
The initial integration date is always depicted in the "date" entry of
the wgrib-table. The grib-1 file is here taken, for which the wgrib-
survey gives the following:
rec 1:0:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2 levels=(0,2)
grid=255 2 m above gnd anl:
TMP=Temp. [K]
timerange 0 P1 0 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0 num_in_ave 0
missing 0
center 4 subcenter 255 process 135 Table 2
latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan 64
mode 136 bdsgrid 1
min/max data 281.56 301.735 num bits 16 BDS_Ref 281.56 DecScale 0
BinScale -11
rec 2:181312:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 1hr fcst:
TMP=Temp. [K]
timerange 0 P1 1 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0 num_in_ave 0
missing 0
center 4 subcenter 255 process 135 Table 2
latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan 64
mode 136 bdsgrid 1
min/max data 281.598 301.614 num bits 16 BDS_Ref 281.598 DecScale
0 BinScale -11
.............................................
rec 43:7615104:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 42hr fcst:
TMP=Temp. [K]
timerange 0 P1 42 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0 num_in_ave
0 missing 0
center 4 subcenter 255 process 135 Table 2
latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan 64
mode 136 bdsgrid 1
min/max data 283.703 305.371 num bits 16 BDS_Ref 283.703 DecScale
0 BinScale -11
Observations (44 cases) were taken from the time interval
20120801_030000 - 20120801_030408 (data file "MET_01_TA_2012-08-
01.txt").
1. E X P E R I M E N T S WITH METv3.1
The config-file:
//
// The model being verified.
model = "COSMO2";
beg_ds = -5400;
end_ds = 5400;
fcst_field[] = ["TMP/Z2" ];
obs_field[] = [];
fcst_thresh[] = ["gt295"];
obs_thresh[] = [];
fcst_wind_thresh[] = [ "NA" ];
obs_wind_thresh[] = [];
message_type[] = [ "ADPSFC" ];
mask_grid[] = [ "FULL" ];
mask_poly[] = [];
mask_sid = "";
// confidence intervals.
ci_alpha[] = [ 0.05 ];
boot_interval = 1;
boot_rep_prop = 1.0;
n_boot_rep = 1000;
boot_rng = "mt19937";
boot_seed = "";
interp_method[] = [ "UW_MEAN" ];
interp_width[] = [ 1 ];
interp_thresh = 1.0;
// 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
output_flag[] = [ 2, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2 ];
rank_corr_flag = 1;
grib_ptv = 2;
tmp_dir = "/tmp";
output_prefix = "";
version = "V3.1";
Here is my script for METv3.1 experiments with the lead-time:
#!bin/bash
# M E T v3.1
# lead time definition
WGR='/home/ogmdp/opt/bin'
MET='/home/ogmdp/tool/METv3.1/bin'
$WGR/wgrib Sochi2_T_2M.grb1 -V >Sochi2_T_2M.grb1.wgrib.out
$MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01.nc -v 2
LEAD=0
while let "LEAD <= 6"
do
echo $LEAD
OUT=out_1_$LEAD
mkdir $OUT
$MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01.nc
PointStatConfig_1 \
-outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v 2 \
-fcst_lead $LEAD
let "LEAD=LEAD + 1"
done
The point_stat debuggings are as follows. For the lead time=0 quite
expected 0 pairs in verification are obtained, all other names and
values are in place:
DEBUG 1: Default Config File:
/home/ogmdp/tool/METv3.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: PointStatConfig_1
DEBUG 1: Forecast File: Sochi2_T_2M.grb1
DEBUG 1: Climatology File: none
DEBUG 1: Observation File: MET_01_TA_2012-08-01.nc
DEBUG 2:
DEBUG 2:
----------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/Z2.
DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology levels.
DEBUG 2:
DEBUG 2:
----------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 44 observations from 44 messages.
DEBUG 2:
DEBUG 2:
----------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC,
over region FULL,
for interpolation method UW_MEAN(1), using 0 pairs.
DEBUG 2:
DEBUG 2:
----------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file: out_1_0/point_stat_000000L_20120801_000000V.stat
DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_fho.txt
DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_ctc.txt
DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_cts.txt
DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_mpr.txt
For the lead time = 3, another quite expected value of 44 pairs with
reasonable statistical tables is obtained (dir names out_1_*) :
......
DEBUG 2:
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC,
over region FULL,
for interpolation method UW_MEAN(1), using 44 pairs.
DEBUG 2: Computing Categorical Statistics.
......
1. E X P E R I M E N T S WITH METv4.0
The config-file:
//
model = "COSMO2";
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
}
];
};
obs = fcst;
obs_window = {
beg = -5400;
end = 5400;
}
mask = {
grid = ["FULL"];
poly = [];
sid = "";
};
//
ci_alpha = [ 0.05 ];
boot = {
interval = PCTILE;
rep_prop = 1.0;
n_rep = 1000;
rng = "mt19937";
seed = "";
};
interp = {
vld_thresh = 1.0;
type = [
{
method = UW_MEAN;
width = 1;
}
];
};
output_flag = {
fho = BOTH;
ctc = BOTH;
cts = BOTH;
mctc = NONE;
mcts = NONE;
cnt = NONE;
sl1l2 = NONE;
sal1l2 = NONE;
vl1l2 = NONE;
val1l2 = NONE;
pct = NONE;
pstd = NONE;
pjc = NONE;
prc = NONE;
mpr = BOTH;
};
duplicate_flag = NONE;
rank_corr_flag = TRUE;
tmp_dir = "/tmp";
output_prefix = "";
version = "V4.0";
The METv4.0 experiment without optional parameters in the command line
did not result in any verification statistics (zero pairs in
processing).
Since there is no explicit "-fcst_lead" switch, I tried the
-obs_valid_beg and -obs_valid_end parameters (what else could I do?):
Here is the corresponding script:
# M E T v4.0
# lead time definition
MET='/home/ogmdp/tool/METv4.0/bin'
$MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01_2.nc
-v 2
LEAD=0
while let "LEAD <= 6"
do
HH=0$LEAD
OUT=out_2_$LEAD
rmdir $OUT
mkdir $OUT
$MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01_2.nc
PointStatConfig_2 \
-outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v 2 \
-obs_valid_beg 20120801_$HH \
-obs_valid_end 20120801_$HH
let "LEAD=LEAD + 1"
done
The statistical output is attached with dir names out_2_*. The
debuggings did bring something encouraging in the LEAD=3 case
(25 pairs!?):
............
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type ADPSFC,
over region FULL, for interpolation method UW_MEAN(1), using 25 pairs.
DEBUG 2: Computing Categorical Statistics.
DEBUG 2:
DEBUG 2:
----------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file: out_2_3/point_stat_000000L_20120801_000000V.stat
DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_fho.txt
DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_ctc.txt
DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_cts.txt
DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_mpr.txt
John, I am very sorry for such a long letter, the desired resolution
is obviously not where I searched and where I stayed. So I need your
help again and would be grateful for your advice.
Regards,
Anatoly
JHGvR> Anatoly,
JHGvR> I'll answer your second question first...
JHGvR> I've created a task in our issue tracking system to update the
JHGvR> MET User's Guide and MET Online Tutorial to include information
JHGvR> about the optional plot_point_obs and plot_data_plane utility
tools. To
JHGvR> see the usage statement for plot_data_plane, just call it with
no arguments:
JHGvR> [johnhg at rambler]% ./plot_data_plane
JHGvR> *** Model Evaluation Tools (METV4.0) ***
JHGvR> Usage: plot_data_plane
JHGvR> input_filename
JHGvR> output_filename
JHGvR> config_string
JHGvR> [-color_table color_table_name]
JHGvR> [-plot_range min max]
JHGvR> [-title title_string]
JHGvR> [-log file]
JHGvR> [-v level]
JHGvR>
JHGvR> where "input_filename" is the name of a gridded data
file to be plotted (required).
JHGvR> "output_filename" is the name of the output
JHGvR> PostScript file to be written (required).
JHGvR> "config_string" defines the data to be plotted
JHGvR> from the input file (required).
JHGvR> "-color_table color_table_name" overrides the
JHGvR> default color table
JHGvR> ("$(MET_BASE_DIR)/data/colortables/met_default.ctable")
(optional).
JHGvR> "-plot_range min max" defines the range of the data
to be plotted (optional).
JHGvR> "-title title_string" specifies the plot title
string (optional).
JHGvR> "-log file" outputs log messages to the specified
file (optional).
JHGvR> "-v level" overrides the default level of logging
(2) (optional).
JHGvR> Here's an example of running it using some test data included
with MET:
JHGvR> METv4.0/bin/plot_data_plane \
JHGvR>
METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
JHGvR> test.ps \
JHGvR> 'name="TMP"; level="Z2";'
JHGvR> The tricky part is often the last entry, the "config_string".
JHGvR> This is the information used to select out a 2D slice of data
JHGvR> from the input file. You specify this in exactly the same way
you specify
JHGvR> data in the "field" entry in the PointStatConfig file.
JHGvR> Usually, you can just list the "name" and "level" you want, but
JHGvR> if there are multiple fields that match that description, you
can provide more
JHGvR> filtering information. Look in METv4.0/data/config/README for
more info.
JHGvR> For example, if you want to specify the record that has a
JHGvR> particular lead time, you'd use this config_string:
JHGvR> 'name="TMP"; level="Z2"; lead_time="12";'
JHGvR> Now run the same command but using a lead time not contained in
that sample file:
JHGvR> 'name="TMP"; level="Z2"; lead_time="15";'
JHGvR> You should get this error message:
JHGvR> ERROR :
JHGvR> ERROR : plot_data_plane -> trouble getting field "name="TMP";
JHGvR> level="Z2"; lead_time="15";" from file
JHGvR> "METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212"
JHGvR> ERROR :
JHGvR> I'm a little unclear on the issue you're describing in your
first question.
JHGvR> Could you please send me an example of MET input/output that
demonstrates the issue?
JHGvR> www.dtcenter.org/met/users/support/met_help.php#ftp
JHGvR> All of the STAT output files include common header columns
JHGvR> that contain, among other things, timing information. For each
JHGvR> field that's evaluated, that includes the forecast lead and
valid times.
JHGvR> Those times should correspond to the times defined in the data
JHGvR> you're verifying. We also include timing information for the
JHGvR> observations in case you want to verifying a forecast at one
time against
JHGvR> observations at another. But are you saying that when
JHGvR> verifying GRIB2 data, the times in the MET output do not
JHGvR> correspond to the times in the GRIB2 files?
JHGvR> Thanks,
JHGvR> John
JHGvR> On 10/08/2012 03:26 AM, muravev at mecom.ru via RT wrote:
>> Mon Oct 08 03:26:13 2012: Request 58608 was acted upon.
>> Transaction: Ticket created by muravev at mecom.ru
>> Queue: met_help
>> Subject: leadtime-in-METv4.0
>> Owner: Nobody
>> Requestors: muravev at mecom.ru
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>> Dear John,
>> Thank you for redirecting my questions to Paul, I got the answer.
>> Could you help me with other two things for which I did not find
suffucient explanation in the User's Guide?
>> 1. There was a lead time parameter in METv3.1 point_stat tool
efficient for our ONE variable forecast grib-1 files with records
consecutively corresponding to fields of analysis (zero lead), 1hr
fcst, 2hr fcst, etc.
>> We retained this file structure for the grib-2 format of the COSMO
model output. But our final statistical METv.4 tables indicate a
constant forecast date for all records as if the forecast time is not
calculated from the grib-2 tables.
>> In the MET demonstration examples, the 'valid fcst time' was one
for all records in a particular forecast data file with multiple
variables. No need of any extra lead time definition.
>> Certainly, I can extract fcst records with the 'valid time' I need
for the verification against observations given. But maybe there is
some other way to point at the lead time for the file organized in our
manner without additional records' scattering?
>> 2. I applied simple MET internal graphics of plot_point_obs tool to
solve these problems with the grid definition. But there are no hints
of how to use plot_data_plane. May I ask you to send me an example or
the list of options for this additional MET tool?
>> Thank you in advance,
>> best regards,
>> Anatoly
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #58608] leadtime-in-METv4.0
From: John Halley Gotway
Time: Tue Oct 09 09:35:16 2012
Anatoly,
OK, I think I understand. The METv3.1 version of the Point-Stat tool
included command line options for specifying "-fcst_lead" and "-
fcst_valid". And in METv4.0, they are no longer present. Similar
changes we made to the other MET statistics tools - removing the
command line options for "-fcst_lead", "-fcst_valid", "-obs_lead", and
"-obs_valid".
The good news is that that filtering functionality was not removed.
Instead, it was moved from the command line into the configuration
files. This is mentioned in the release notes for METv4.0:
http://www.dtcenter.org/met/users/support/release_notes/METv4.0_release_notes.php
I was expecting that we'd included details on this in the
METv4.0/data/config/README file, but unfortunately, I see that we have
not. I'll update that file for the next release.
You can use the following settings in the config file to indicate
which times should be used:
lead_time = HH[MMSS];
init_time = YYYYMMDD[_HH[MMSS]];
valid_time = YYYYMMDD[_HH[MMSS]];
So you can specify the initialization, valid, and/or lead times that
should be extracted from the input files. These entries can be used
in the "field" array where you select the fields to be
verified. For example:
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
lead_time = "01";
}
];
};
By setting this, you'll only match forecasts with a 1-hour lead time.
Now there are a few subtleties about this I'd like to explain...
(1) In the example above, the "lead_time" entry is defined for that
single TMP/Z2 field. If you were verifying multiple fields, you could
define lead_time once at a higher level. In the example
below, the lead_time setting will apply to both fields:
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ];
lead_time = "01";
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
},
{
name = "RH";
level = [ "Z2" ];
cat_thresh = [ >0.10 ];
},
];
};
(2) Since your GRIB file contains multiple times, you could choose to
verify all of them in a single call to Point-Stat. But you'd need to
pass all the verifying observations to Point-Stat as well.
That would look like this:
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
lead_time = "00";
},
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
lead_time = "01";
},
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
lead_time = "02";
}
... and so on
];
};
(3) Or perhaps you want to script it up and make use of environment
variables. Suppose, prior to running Point-Stat, you've set the
FCST_LEAD environment variable to "01":
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ >295 ];
lead_time = ${FCST_LEAD};
}
];
};
Hopefully that'll get you going on METv4.0.
Thanks for the feedback,
John
On 10/09/2012 06:03 AM, muravev at mecom.ru via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>
> Dear John,
>
> Thank you very much for your explanation for the plot_data_plane
tool. What I was interested in was just the 'tricky part', now I see
how it works.
>
> Again, my principal question was about the lead time definition in
the comand-line of the point_stat tool. In the model test files
Sochi2_T_2M.grb1/grb2 the only variable TMP at Z2 with 43 hourly
records corresponding to lead-time intervals is given, where rec-1 is
2012080100 analysis field, rec-2 is 2012080101 fcst field etc.
>
> The initial integration date is always depicted in the "date" entry
of the wgrib-table. The grib-1 file is here taken, for which the
wgrib-survey gives the following:
>
> rec 1:0:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2 levels=(0,2)
grid=255 2 m above gnd anl:
> TMP=Temp. [K]
> timerange 0 P1 0 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
> center 4 subcenter 255 process 135 Table 2
> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
> long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan
64 mode 136 bdsgrid 1
> min/max data 281.56 301.735 num bits 16 BDS_Ref 281.56
DecScale 0 BinScale -11
>
> rec 2:181312:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 1hr fcst:
> TMP=Temp. [K]
> timerange 0 P1 1 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
> center 4 subcenter 255 process 135 Table 2
> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
> long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan
64 mode 136 bdsgrid 1
> min/max data 281.598 301.614 num bits 16 BDS_Ref 281.598
DecScale 0 BinScale -11
> .............................................
> rec 43:7615104:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 42hr fcst:
> TMP=Temp. [K]
> timerange 0 P1 42 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
> center 4 subcenter 255 process 135 Table 2
> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
> long 37.700000 to 41.450000 by 0.013000, (301 x 301) scan
64 mode 136 bdsgrid 1
> min/max data 283.703 305.371 num bits 16 BDS_Ref 283.703
DecScale 0 BinScale -11
>
>
> Observations (44 cases) were taken from the time interval
20120801_030000 - 20120801_030408 (data file "MET_01_TA_2012-08-
01.txt").
>
>
> 1. E X P E R I M E N T S WITH METv3.1
>
> The config-file:
> //
> // The model being verified.
> model = "COSMO2";
> beg_ds = -5400;
> end_ds = 5400;
> fcst_field[] = ["TMP/Z2" ];
> obs_field[] = [];
> fcst_thresh[] = ["gt295"];
> obs_thresh[] = [];
> fcst_wind_thresh[] = [ "NA" ];
> obs_wind_thresh[] = [];
> message_type[] = [ "ADPSFC" ];
> mask_grid[] = [ "FULL" ];
> mask_poly[] = [];
> mask_sid = "";
> // confidence intervals.
> ci_alpha[] = [ 0.05 ];
> boot_interval = 1;
> boot_rep_prop = 1.0;
> n_boot_rep = 1000;
> boot_rng = "mt19937";
> boot_seed = "";
> interp_method[] = [ "UW_MEAN" ];
> interp_width[] = [ 1 ];
> interp_thresh = 1.0;
> // 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> output_flag[] = [ 2, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2 ];
> rank_corr_flag = 1;
> grib_ptv = 2;
> tmp_dir = "/tmp";
> output_prefix = "";
> version = "V3.1";
>
>
> Here is my script for METv3.1 experiments with the lead-time:
>
> #!bin/bash
> # M E T v3.1
> # lead time definition
> WGR='/home/ogmdp/opt/bin'
> MET='/home/ogmdp/tool/METv3.1/bin'
>
> $WGR/wgrib Sochi2_T_2M.grb1 -V >Sochi2_T_2M.grb1.wgrib.out
> $MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01.nc -v
2
> LEAD=0
> while let "LEAD <= 6"
> do
> echo $LEAD
> OUT=out_1_$LEAD
> mkdir $OUT
>
> $MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01.nc
PointStatConfig_1 \
> -outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v 2 \
> -fcst_lead $LEAD
> let "LEAD=LEAD + 1"
> done
>
>
> The point_stat debuggings are as follows. For the lead time=0 quite
expected 0 pairs in verification are obtained, all other names and
values are in place:
>
> DEBUG 1: Default Config File:
/home/ogmdp/tool/METv3.1/data/config/PointStatConfig_default
> DEBUG 1: User Config File: PointStatConfig_1
> DEBUG 1: Forecast File: Sochi2_T_2M.grb1
> DEBUG 1: Climatology File: none
> DEBUG 1: Observation File: MET_01_TA_2012-08-01.nc
> DEBUG 2:
> DEBUG 2:
----------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/Z2.
> DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
----------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Searching 44 observations from 44 messages.
> DEBUG 2:
> DEBUG 2:
----------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL,
> for interpolation method UW_MEAN(1), using 0 pairs.
> DEBUG 2:
> DEBUG 2:
----------------------------------------------------------------------
> DEBUG 2:
> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V.stat
> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_fho.txt
> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_ctc.txt
> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_cts.txt
> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_mpr.txt
>
>
> For the lead time = 3, another quite expected value of 44 pairs with
reasonable statistical tables is obtained (dir names out_1_*) :
> ......
> DEBUG 2:
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL,
> for interpolation method UW_MEAN(1), using 44 pairs.
> DEBUG 2: Computing Categorical Statistics.
> ......
>
>
> 1. E X P E R I M E N T S WITH METv4.0
>
> The config-file:
>
> //
> model = "COSMO2";
> fcst = {
> wind_thresh = [ NA ];
> message_type = [ "ADPSFC" ];
> field = [
> {
> name = "TMP";
> level = [ "Z2" ];
> cat_thresh = [ >295 ];
> }
> ];
> };
> obs = fcst;
> obs_window = {
> beg = -5400;
> end = 5400;
> }
> mask = {
> grid = ["FULL"];
> poly = [];
> sid = "";
> };
> //
> ci_alpha = [ 0.05 ];
> boot = {
> interval = PCTILE;
> rep_prop = 1.0;
> n_rep = 1000;
> rng = "mt19937";
> seed = "";
> };
> interp = {
> vld_thresh = 1.0;
>
> type = [
> {
> method = UW_MEAN;
> width = 1;
> }
> ];
> };
> output_flag = {
> fho = BOTH;
> ctc = BOTH;
> cts = BOTH;
> mctc = NONE;
> mcts = NONE;
> cnt = NONE;
> sl1l2 = NONE;
> sal1l2 = NONE;
> vl1l2 = NONE;
> val1l2 = NONE;
> pct = NONE;
> pstd = NONE;
> pjc = NONE;
> prc = NONE;
> mpr = BOTH;
> };
> duplicate_flag = NONE;
> rank_corr_flag = TRUE;
> tmp_dir = "/tmp";
> output_prefix = "";
> version = "V4.0";
>
>
>
> The METv4.0 experiment without optional parameters in the command
line did not result in any verification statistics (zero pairs in
processing).
>
> Since there is no explicit "-fcst_lead" switch, I tried the
-obs_valid_beg and -obs_valid_end parameters (what else could I do?):
>
> Here is the corresponding script:
>
> # M E T v4.0
> # lead time definition
> MET='/home/ogmdp/tool/METv4.0/bin'
> $MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01_2.nc
-v 2
> LEAD=0
> while let "LEAD <= 6"
> do
> HH=0$LEAD
> OUT=out_2_$LEAD
> rmdir $OUT
> mkdir $OUT
> $MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01_2.nc
PointStatConfig_2 \
> -outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v 2
\
> -obs_valid_beg 20120801_$HH \
> -obs_valid_end 20120801_$HH
> let "LEAD=LEAD + 1"
> done
>
>
> The statistical output is attached with dir names out_2_*. The
debuggings did bring something encouraging in the LEAD=3 case
> (25 pairs!?):
> ............
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using
25 pairs.
> DEBUG 2: Computing Categorical Statistics.
> DEBUG 2:
> DEBUG 2:
----------------------------------------------------------------------
> DEBUG 2:
> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V.stat
> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_fho.txt
> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_ctc.txt
> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_cts.txt
> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_mpr.txt
>
> John, I am very sorry for such a long letter, the desired resolution
is obviously not where I searched and where I stayed. So I need your
help again and would be grateful for your advice.
>
> Regards,
> Anatoly
>
>
>
>
> JHGvR> Anatoly,
>
> JHGvR> I'll answer your second question first...
>
> JHGvR> I've created a task in our issue tracking system to update
the
> JHGvR> MET User's Guide and MET Online Tutorial to include
information
> JHGvR> about the optional plot_point_obs and plot_data_plane utility
tools. To
> JHGvR> see the usage statement for plot_data_plane, just call it
with no arguments:
>
> JHGvR> [johnhg at rambler]% ./plot_data_plane
>
> JHGvR> *** Model Evaluation Tools (METV4.0) ***
>
> JHGvR> Usage: plot_data_plane
> JHGvR> input_filename
> JHGvR> output_filename
> JHGvR> config_string
> JHGvR> [-color_table color_table_name]
> JHGvR> [-plot_range min max]
> JHGvR> [-title title_string]
> JHGvR> [-log file]
> JHGvR> [-v level]
> JHGvR>
>
> JHGvR> where "input_filename" is the name of a gridded data
file to be plotted (required).
> JHGvR> "output_filename" is the name of the output
> JHGvR> PostScript file to be written (required).
> JHGvR> "config_string" defines the data to be plotted
> JHGvR> from the input file (required).
> JHGvR> "-color_table color_table_name" overrides the
> JHGvR> default color table
> JHGvR> ("$(MET_BASE_DIR)/data/colortables/met_default.ctable")
(optional).
> JHGvR> "-plot_range min max" defines the range of the
data to be plotted (optional).
> JHGvR> "-title title_string" specifies the plot title
string (optional).
> JHGvR> "-log file" outputs log messages to the specified
file (optional).
> JHGvR> "-v level" overrides the default level of logging
(2) (optional).
>
> JHGvR> Here's an example of running it using some test data included
with MET:
> JHGvR> METv4.0/bin/plot_data_plane \
> JHGvR>
METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
> JHGvR> test.ps \
> JHGvR> 'name="TMP"; level="Z2";'
>
> JHGvR> The tricky part is often the last entry, the "config_string".
> JHGvR> This is the information used to select out a 2D slice of data
> JHGvR> from the input file. You specify this in exactly the same
way you specify
> JHGvR> data in the "field" entry in the PointStatConfig file.
> JHGvR> Usually, you can just list the "name" and "level" you want,
but
> JHGvR> if there are multiple fields that match that description, you
can provide more
> JHGvR> filtering information. Look in METv4.0/data/config/README
for more info.
>
> JHGvR> For example, if you want to specify the record that has a
> JHGvR> particular lead time, you'd use this config_string:
> JHGvR> 'name="TMP"; level="Z2"; lead_time="12";'
>
> JHGvR> Now run the same command but using a lead time not contained
in that sample file:
> JHGvR> 'name="TMP"; level="Z2"; lead_time="15";'
>
> JHGvR> You should get this error message:
> JHGvR> ERROR :
> JHGvR> ERROR : plot_data_plane -> trouble getting field
"name="TMP";
> JHGvR> level="Z2"; lead_time="15";" from file
> JHGvR>
"METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212"
> JHGvR> ERROR :
>
> JHGvR> I'm a little unclear on the issue you're describing in your
first question.
>
> JHGvR> Could you please send me an example of MET input/output that
demonstrates the issue?
> JHGvR> www.dtcenter.org/met/users/support/met_help.php#ftp
>
> JHGvR> All of the STAT output files include common header columns
> JHGvR> that contain, among other things, timing information. For
each
> JHGvR> field that's evaluated, that includes the forecast lead and
valid times.
> JHGvR> Those times should correspond to the times defined in the
data
> JHGvR> you're verifying. We also include timing information for the
> JHGvR> observations in case you want to verifying a forecast at one
time against
> JHGvR> observations at another. But are you saying that when
> JHGvR> verifying GRIB2 data, the times in the MET output do not
> JHGvR> correspond to the times in the GRIB2 files?
>
> JHGvR> Thanks,
> JHGvR> John
>
>
> JHGvR> On 10/08/2012 03:26 AM, muravev at mecom.ru via RT wrote:
>
>>> Mon Oct 08 03:26:13 2012: Request 58608 was acted upon.
>>> Transaction: Ticket created by muravev at mecom.ru
>>> Queue: met_help
>>> Subject: leadtime-in-METv4.0
>>> Owner: Nobody
>>> Requestors: muravev at mecom.ru
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>
>
>>> Dear John,
>
>>> Thank you for redirecting my questions to Paul, I got the answer.
>
>>> Could you help me with other two things for which I did not find
suffucient explanation in the User's Guide?
>
>>> 1. There was a lead time parameter in METv3.1 point_stat tool
efficient for our ONE variable forecast grib-1 files with records
consecutively corresponding to fields of analysis (zero lead), 1hr
fcst, 2hr fcst, etc.
>
>>> We retained this file structure for the grib-2 format of the COSMO
model output. But our final statistical METv.4 tables indicate a
constant forecast date for all records as if the forecast time is not
calculated from the grib-2 tables.
>
>>> In the MET demonstration examples, the 'valid fcst time' was one
for all records in a particular forecast data file with multiple
variables. No need of any extra lead time definition.
>
>>> Certainly, I can extract fcst records with the 'valid time' I need
for the verification against observations given. But maybe there is
some other way to point at the lead time for the file organized in our
manner without additional records' scattering?
>
>>> 2. I applied simple MET internal graphics of plot_point_obs tool
to solve these problems with the grid definition. But there are no
hints of how to use plot_data_plane. May I ask you to send me an
example or the list of options for this additional MET tool?
>
>
>>> Thank you in advance,
>>> best regards,
>
>>> Anatoly
>
>
------------------------------------------------
Subject: Re[2]: [rt.rap.ucar.edu #58608] leadtime-in-METv4.0
From: muravev at mecom.ru
Time: Wed Oct 10 00:30:47 2012
John,
Thanks a lot! Sorry for not finding proper words at the very beginning
to get the explanation, english is not my native tongue. This "request
has been resolved" and I will go on experimenting with your splendid
product.
Anatoly
JHGvR> Anatoly,
JHGvR> OK, I think I understand. The METv3.1 version of the
JHGvR> Point-Stat tool included command line options for specifying
JHGvR> "-fcst_lead" and "-fcst_valid". And in METv4.0, they are no
longer present. Similar
JHGvR> changes we made to the other MET statistics tools - removing
JHGvR> the command line options for "-fcst_lead", "-fcst_valid", "-
obs_lead", and "-obs_valid".
JHGvR> The good news is that that filtering functionality was not
JHGvR> removed. Instead, it was moved from the command line into the
JHGvR> configuration files. This is mentioned in the release notes
for METv4.0:
JHGvR>
JHGvR>
http://www.dtcenter.org/met/users/support/release_notes/METv4.0_release_notes.php
JHGvR> I was expecting that we'd included details on this in the
JHGvR> METv4.0/data/config/README file, but unfortunately, I see that
JHGvR> we have not. I'll update that file for the next release.
JHGvR> You can use the following settings in the config file to
JHGvR> indicate which times should be used:
JHGvR> lead_time = HH[MMSS];
JHGvR> init_time = YYYYMMDD[_HH[MMSS]];
JHGvR> valid_time = YYYYMMDD[_HH[MMSS]];
JHGvR> So you can specify the initialization, valid, and/or lead
JHGvR> times that should be extracted from the input files. These
JHGvR> entries can be used in the "field" array where you select the
fields to be
JHGvR> verified. For example:
JHGvR> fcst = {
JHGvR> wind_thresh = [ NA ];
JHGvR> message_type = [ "ADPSFC" ];
JHGvR> field = [
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> lead_time = "01";
JHGvR> }
JHGvR> ];
JHGvR> };
JHGvR> By setting this, you'll only match forecasts with a 1-hour lead
time.
JHGvR> Now there are a few subtleties about this I'd like to
explain...
JHGvR> (1) In the example above, the "lead_time" entry is defined for
JHGvR> that single TMP/Z2 field. If you were verifying multiple
JHGvR> fields, you could define lead_time once at a higher level. In
the example
JHGvR> below, the lead_time setting will apply to both fields:
JHGvR> fcst = {
JHGvR> wind_thresh = [ NA ];
JHGvR> message_type = [ "ADPSFC" ];
JHGvR> lead_time = "01";
JHGvR> field = [
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> },
JHGvR> {
JHGvR> name = "RH";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >0.10 ];
JHGvR> },
JHGvR> ];
JHGvR> };
JHGvR> (2) Since your GRIB file contains multiple times, you could
JHGvR> choose to verify all of them in a single call to Point-Stat.
JHGvR> But you'd need to pass all the verifying observations to Point-
Stat as well.
JHGvR> That would look like this:
JHGvR> fcst = {
JHGvR> wind_thresh = [ NA ];
JHGvR> message_type = [ "ADPSFC" ];
JHGvR> field = [
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> lead_time = "00";
JHGvR> },
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> lead_time = "01";
JHGvR> },
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> lead_time = "02";
JHGvR> }
JHGvR> ... and so on
JHGvR> ];
JHGvR> };
JHGvR> (3) Or perhaps you want to script it up and make use of
JHGvR> environment variables. Suppose, prior to running Point-Stat,
JHGvR> you've set the FCST_LEAD environment variable to "01":
JHGvR> fcst = {
JHGvR> wind_thresh = [ NA ];
JHGvR> message_type = [ "ADPSFC" ];
JHGvR> field = [
JHGvR> {
JHGvR> name = "TMP";
JHGvR> level = [ "Z2" ];
JHGvR> cat_thresh = [ >295 ];
JHGvR> lead_time = ${FCST_LEAD};
JHGvR> }
JHGvR> ];
JHGvR> };
JHGvR> Hopefully that'll get you going on METv4.0.
JHGvR> Thanks for the feedback,
JHGvR> John
JHGvR> On 10/09/2012 06:03 AM, muravev at mecom.ru via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>> Dear John,
>> Thank you very much for your explanation for the plot_data_plane
tool. What I was interested in was just the 'tricky part', now I see
how it works.
>> Again, my principal question was about the lead time definition in
the comand-line of the point_stat tool. In the model test files
Sochi2_T_2M.grb1/grb2 the only variable TMP at Z2 with 43 hourly
records corresponding to lead-time intervals is given, where rec-1 is
2012080100 analysis field, rec-2 is 2012080101 fcst field etc.
>> The initial integration date is always depicted in the "date" entry
of the wgrib-table. The grib-1 file is here taken, for which the
wgrib-survey gives the following:
>> rec 1:0:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2 levels=(0,2)
grid=255 2 m above gnd anl:
>> TMP=Temp. [K]
>> timerange 0 P1 0 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
>> center 4 subcenter 255 process 135 Table 2
>> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
>> long 37.700000 to 41.450000 by 0.013000, (301 x 301)
scan 64 mode 136 bdsgrid 1
>> min/max data 281.56 301.735 num bits 16 BDS_Ref 281.56
DecScale 0 BinScale -11
>> rec 2:181312:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 1hr fcst:
>> TMP=Temp. [K]
>> timerange 0 P1 1 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
>> center 4 subcenter 255 process 135 Table 2
>> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
>> long 37.700000 to 41.450000 by 0.013000, (301 x 301)
scan 64 mode 136 bdsgrid 1
>> min/max data 281.598 301.614 num bits 16 BDS_Ref 281.598
DecScale 0 BinScale -11
>> .............................................
>> rec 43:7615104:date 2012080100 TMP kpds5=11 kpds6=105 kpds7=2
levels=(0,2) grid=255 2 m above gnd 42hr fcst:
>> TMP=Temp. [K]
>> timerange 0 P1 42 P2 0 TimeU 1 nx 301 ny 301 GDS grid 0
num_in_ave 0 missing 0
>> center 4 subcenter 255 process 135 Table 2
>> latlon: lat 42.333000 to 45.033000 by 0.009000 nxny 90601
>> long 37.700000 to 41.450000 by 0.013000, (301 x 301)
scan 64 mode 136 bdsgrid 1
>> min/max data 283.703 305.371 num bits 16 BDS_Ref 283.703
DecScale 0 BinScale -11
>> Observations (44 cases) were taken from the time interval
20120801_030000 - 20120801_030408 (data file "MET_01_TA_2012-08-
01.txt").
>> 1. E X P E R I M E N T S WITH METv3.1
>> The config-file:
>> //
>> // The model being verified.
>> model = "COSMO2";
>> beg_ds = -5400;
>> end_ds = 5400;
>> fcst_field[] = ["TMP/Z2" ];
>> obs_field[] = [];
>> fcst_thresh[] = ["gt295"];
>> obs_thresh[] = [];
>> fcst_wind_thresh[] = [ "NA" ];
>> obs_wind_thresh[] = [];
>> message_type[] = [ "ADPSFC" ];
>> mask_grid[] = [ "FULL" ];
>> mask_poly[] = [];
>> mask_sid = "";
>> // confidence intervals.
>> ci_alpha[] = [ 0.05 ];
>> boot_interval = 1;
>> boot_rep_prop = 1.0;
>> n_boot_rep = 1000;
>> boot_rng = "mt19937";
>> boot_seed = "";
>> interp_method[] = [ "UW_MEAN" ];
>> interp_width[] = [ 1 ];
>> interp_thresh = 1.0;
>> // 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>> output_flag[] = [ 2, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2 ];
>> rank_corr_flag = 1;
>> grib_ptv = 2;
>> tmp_dir = "/tmp";
>> output_prefix = "";
>> version = "V3.1";
>> Here is my script for METv3.1 experiments with the lead-time:
>> #!bin/bash
>> # M E T v3.1
>> # lead time definition
>> WGR='/home/ogmdp/opt/bin'
>> MET='/home/ogmdp/tool/METv3.1/bin'
>> $WGR/wgrib Sochi2_T_2M.grb1 -V >Sochi2_T_2M.grb1.wgrib.out
>> $MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01.nc -v
2
>> LEAD=0
>> while let "LEAD <= 6"
>> do
>> echo $LEAD
>> OUT=out_1_$LEAD
>> mkdir $OUT
>> $MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01.nc
PointStatConfig_1 \
>> -outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v 2 \
>> -fcst_lead $LEAD
>> let "LEAD=LEAD + 1"
>> done
>> The point_stat debuggings are as follows. For the lead time=0 quite
expected 0 pairs in verification are obtained, all other names and
values are in place:
>> DEBUG 1: Default Config File:
/home/ogmdp/tool/METv3.1/data/config/PointStatConfig_default
>> DEBUG 1: User Config File: PointStatConfig_1
>> DEBUG 1: Forecast File: Sochi2_T_2M.grb1
>> DEBUG 1: Climatology File: none
>> DEBUG 1: Observation File: MET_01_TA_2012-08-01.nc
>> DEBUG 2:
>> DEBUG 2:
----------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Reading data for TMP/Z2.
>> DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology
levels.
>> DEBUG 2:
>> DEBUG 2:
----------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Searching 44 observations from 44 messages.
>> DEBUG 2:
>> DEBUG 2:
----------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL,
>> for interpolation method UW_MEAN(1), using 0 pairs.
>> DEBUG 2:
>> DEBUG 2:
----------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V.stat
>> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_fho.txt
>> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_ctc.txt
>> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_cts.txt
>> DEBUG 1: Output file:
out_1_0/point_stat_000000L_20120801_000000V_mpr.txt
>> For the lead time = 3, another quite expected value of 44 pairs
with reasonable statistical tables is obtained (dir names out_1_*) :
>> ......
>> DEBUG 2:
>> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL,
>> for interpolation method UW_MEAN(1), using 44 pairs.
>> DEBUG 2: Computing Categorical Statistics.
>> ......
>> 1. E X P E R I M E N T S WITH METv4.0
>> The config-file:
>> //
>> model = "COSMO2";
>> fcst = {
>> wind_thresh = [ NA ];
>> message_type = [ "ADPSFC" ];
>> field = [
>> {
>> name = "TMP";
>> level = [ "Z2" ];
>> cat_thresh = [ >295 ];
>> }
>> ];
>> };
>> obs = fcst;
>> obs_window = {
>> beg = -5400;
>> end = 5400;
>> }
>> mask = {
>> grid = ["FULL"];
>> poly = [];
>> sid = "";
>> };
>> //
>> ci_alpha = [ 0.05 ];
>> boot = {
>> interval = PCTILE;
>> rep_prop = 1.0;
>> n_rep = 1000;
>> rng = "mt19937";
>> seed = "";
>> };
>> interp = {
>> vld_thresh = 1.0;
>> type = [
>> {
>> method = UW_MEAN;
>> width = 1;
>> }
>> ];
>> };
>> output_flag = {
>> fho = BOTH;
>> ctc = BOTH;
>> cts = BOTH;
>> mctc = NONE;
>> mcts = NONE;
>> cnt = NONE;
>> sl1l2 = NONE;
>> sal1l2 = NONE;
>> vl1l2 = NONE;
>> val1l2 = NONE;
>> pct = NONE;
>> pstd = NONE;
>> pjc = NONE;
>> prc = NONE;
>> mpr = BOTH;
>> };
>> duplicate_flag = NONE;
>> rank_corr_flag = TRUE;
>> tmp_dir = "/tmp";
>> output_prefix = "";
>> version = "V4.0";
>> The METv4.0 experiment without optional parameters in the command
line did not result in any verification statistics (zero pairs in
processing).
>> Since there is no explicit "-fcst_lead" switch, I tried the
-obs_valid_beg and -obs_valid_end parameters (what else could I do?):
>> Here is the corresponding script:
>> # M E T v4.0
>> # lead time definition
>> MET='/home/ogmdp/tool/METv4.0/bin'
>> $MET/ascii2nc MET_01_TA_2012-08-01.txt MET_01_TA_2012-08-01_2.nc
-v 2
>> LEAD=0
>> while let "LEAD <= 6"
>> do
>> HH=0$LEAD
>> OUT=out_2_$LEAD
>> rmdir $OUT
>> mkdir $OUT
>> $MET/point_stat Sochi2_T_2M.grb1 MET_01_TA_2012-08-01_2.nc
PointStatConfig_2 \
>> -outdir $OUT -log MET_01_TA_2012-08-01.$OUT -v
2 \
>> -obs_valid_beg 20120801_$HH \
>> -obs_valid_end 20120801_$HH
>> let "LEAD=LEAD + 1"
>> done
>> The statistical output is attached with dir names out_2_*. The
debuggings did bring something encouraging in the LEAD=3 case
>> (25 pairs!?):
>> ............
>> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN(1), using
25 pairs.
>> DEBUG 2: Computing Categorical Statistics.
>> DEBUG 2:
>> DEBUG 2:
----------------------------------------------------------------------
>> DEBUG 2:
>> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V.stat
>> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_fho.txt
>> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_ctc.txt
>> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_cts.txt
>> DEBUG 1: Output file:
out_2_3/point_stat_000000L_20120801_000000V_mpr.txt
>> John, I am very sorry for such a long letter, the desired
resolution is obviously not where I searched and where I stayed. So I
need your help again and would be grateful for your advice.
>> Regards,
>> Anatoly
>> JHGvR> Anatoly,
>> JHGvR> I'll answer your second question first...
>> JHGvR> I've created a task in our issue tracking system to update
the
>> JHGvR> MET User's Guide and MET Online Tutorial to include
information
>> JHGvR> about the optional plot_point_obs and plot_data_plane
utility tools. To
>> JHGvR> see the usage statement for plot_data_plane, just call it
with no arguments:
>> JHGvR> [johnhg at rambler]% ./plot_data_plane
>> JHGvR> *** Model Evaluation Tools (METV4.0) ***
>> JHGvR> Usage: plot_data_plane
>> JHGvR> input_filename
>> JHGvR> output_filename
>> JHGvR> config_string
>> JHGvR> [-color_table color_table_name]
>> JHGvR> [-plot_range min max]
>> JHGvR> [-title title_string]
>> JHGvR> [-log file]
>> JHGvR> [-v level]
>> JHGvR>
>> JHGvR> where "input_filename" is the name of a gridded data
file to be plotted (required).
>> JHGvR> "output_filename" is the name of the output
>> JHGvR> PostScript file to be written (required).
>> JHGvR> "config_string" defines the data to be plotted
>> JHGvR> from the input file (required).
>> JHGvR> "-color_table color_table_name" overrides the
>> JHGvR> default color table
>> JHGvR> ("$(MET_BASE_DIR)/data/colortables/met_default.ctable")
(optional).
>> JHGvR> "-plot_range min max" defines the range of the
data to be plotted (optional).
>> JHGvR> "-title title_string" specifies the plot title
string (optional).
>> JHGvR> "-log file" outputs log messages to the
specified file (optional).
>> JHGvR> "-v level" overrides the default level of
logging (2) (optional).
>> JHGvR> Here's an example of running it using some test data
included with MET:
>> JHGvR> METv4.0/bin/plot_data_plane \
>> JHGvR>
METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212 \
>> JHGvR> test.ps \
>> JHGvR> 'name="TMP"; level="Z2";'
>> JHGvR> The tricky part is often the last entry, the
"config_string".
>> JHGvR> This is the information used to select out a 2D slice of
data
>> JHGvR> from the input file. You specify this in exactly the same
way you specify
>> JHGvR> data in the "field" entry in the PointStatConfig file.
>> JHGvR> Usually, you can just list the "name" and "level" you want,
but
>> JHGvR> if there are multiple fields that match that description,
you can provide more
>> JHGvR> filtering information. Look in METv4.0/data/config/README
for more info.
>> JHGvR> For example, if you want to specify the record that has a
>> JHGvR> particular lead time, you'd use this config_string:
>> JHGvR> 'name="TMP"; level="Z2"; lead_time="12";'
>> JHGvR> Now run the same command but using a lead time not contained
in that sample file:
>> JHGvR> 'name="TMP"; level="Z2"; lead_time="15";'
>> JHGvR> You should get this error message:
>> JHGvR> ERROR :
>> JHGvR> ERROR : plot_data_plane -> trouble getting field
"name="TMP";
>> JHGvR> level="Z2"; lead_time="15";" from file
>> JHGvR>
"METv4.0/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212"
>> JHGvR> ERROR :
>> JHGvR> I'm a little unclear on the issue you're describing in your
first question.
>> JHGvR> Could you please send me an example of MET input/output that
demonstrates the issue?
>> JHGvR> www.dtcenter.org/met/users/support/met_help.php#ftp
>> JHGvR> All of the STAT output files include common header columns
>> JHGvR> that contain, among other things, timing information. For
each
>> JHGvR> field that's evaluated, that includes the forecast lead and
valid times.
>> JHGvR> Those times should correspond to the times defined in the
data
>> JHGvR> you're verifying. We also include timing information for
the
>> JHGvR> observations in case you want to verifying a forecast at one
time against
>> JHGvR> observations at another. But are you saying that when
>> JHGvR> verifying GRIB2 data, the times in the MET output do not
>> JHGvR> correspond to the times in the GRIB2 files?
>> JHGvR> Thanks,
>> JHGvR> John
>> JHGvR> On 10/08/2012 03:26 AM, muravev at mecom.ru via RT wrote:
>>>> Mon Oct 08 03:26:13 2012: Request 58608 was acted upon.
>>>> Transaction: Ticket created by muravev at mecom.ru
>>>> Queue: met_help
>>>> Subject: leadtime-in-METv4.0
>>>> Owner: Nobody
>>>> Requestors: muravev at mecom.ru
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58608 >
>>>> Dear John,
>>>> Thank you for redirecting my questions to Paul, I got the answer.
>>>> Could you help me with other two things for which I did not find
suffucient explanation in the User's Guide?
>>>> 1. There was a lead time parameter in METv3.1 point_stat tool
efficient for our ONE variable forecast grib-1 files with records
consecutively corresponding to fields of analysis (zero lead), 1hr
fcst, 2hr fcst, etc.
>>>> We retained this file structure for the grib-2 format of the
COSMO model output. But our final statistical METv.4 tables indicate a
constant forecast date for all records as if the forecast time is not
calculated from the grib-2 tables.
>>>> In the MET demonstration examples, the 'valid fcst time' was one
for all records in a particular forecast data file with multiple
variables. No need of any extra lead time definition.
>>>> Certainly, I can extract fcst records with the 'valid time' I
need for the verification against observations given. But maybe there
is some other way to point at the lead time for the file organized in
our manner without additional records' scattering?
>>>> 2. I applied simple MET internal graphics of plot_point_obs tool
to solve these problems with the grid definition. But there are no
hints of how to use plot_data_plane. May I ask you to send me an
example or the list of options for this additional MET tool?
>>>> Thank you in advance,
>>>> best regards,
>>>> Anatoly
------------------------------------------------
More information about the Met_help
mailing list