[Met_help] [rt.rap.ucar.edu #62337] History for generating my own poly_mask and reading rain variable for point_stat
John Halley Gotway via RT
met_help at ucar.edu
Tue Aug 27 11:00:03 MDT 2013
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
1. Is there a standard method of creating a poly-mask? My region is over West Africa.
2. If I am reading both an observation (ascii2nc) file and plev-wrfout file into point stat and they both contain the same variable of precipitation, 'ACC_RAIN,'
what do I change in point_stat configuration file? The example documentation shows:
16 //
17 // Forecast and observation fields to be verified
18 //
19 fcst = {
20 wind_thresh = [ NA ];
21 message_type = [ "ADPUPA", "ADPSFC" ];
22
23 field = [
24 {
25 name = "TMP";
26 level = [ "P750-900" ];
27 cat_thresh = [ <=273, >273 ];
28 },
29
30 {
31 name = "UGRD";
32 level = [ "Z10" ];
33 cat_thresh = [ >=5 ];
34 },
35
36 {
37 name = "VGRD";
38 level = [ "Z10" ];
39 cat_thresh = [ >=5 ];
40 }
41 ];
42
43 };
44 obs = fcst;
45
Is this saying that I should just replace the above text with the following and that is it?
16 //
17 // Forecast and observation fields to be verified
18 //
19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
20 obs = fcst;
45
Thank you.
-Erik
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #62337] generating my own poly_mask and reading rain variable for point_stat
From: John Halley Gotway
Time: Mon Jul 22 14:10:42 2013
Erik,
To create a polyline mask, you simply create an ASCII file containing
a list of lat/lons that define the region of interest. For example,
take a look at METv4.1/data/poly/SWC.poly. The first line of
the file specifies the name for the polyline. And the remaining lines
contain lat/lon values for the boundary points. The last point is
connected back up to the first point to complete the area.
The example is named "SWC" and contains 33 points. You need a minimum
of 3 points to define a polyline, and there is no real maximum.
You can use this ASCII file directly in the Point-Stat config file.
For example...
poly = [ "MET_BASE/data/poly/SWC.poly" ];
If your polyline contains a large number of points (a few hundred) or
you have many grid-points, the process of determining which grid
points are inside/outside the polyline can be slow. In that
case, I'd suggest running your polyline through the gen_poly_mask
tool. It's described here:
http://www.dtcenter.org/met/users/support/online_tutorial/METv4.0/gen_poly_mask/index.php
Basically, you apply the polyline once to your domain to create a 0/1
bitmap. Then you pass that to Point-Stat:
poly = [ "output/of/gen_poly_mask.nc" ];
I'm a bit confused about your second question. You say that your
ASCII2NC output contains a variable named "ACC_RAIN". That shouldn't
be the case. Assuming it really is the output of ASCII2NC,
here's how you'd set it up:
fcst = {
wind_thresh = [ NA ];
field = [
{
name = "ACC_RAIN";
level = [ "(*.*)" ];
cat_thresh = [ >0 ]; // or whatever thresholds you'd like
}
];
};
obs = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC" ]; // I assume you've used the ADPSFC
message type for precip
field = [
{
name = "APCP";
level = [ "A06" ]; // or whatever the accumulation
interval is
cat_thresh = [ >0 ]; // or whatever thresholds you'd like
}
];
};
The forecast field is NetCDF, so you tell Point-Stat the variable
name/level info that way: ACC_RAIN(*,*)
By convention, the observation field in Point-Stat is specified using
the GRIB conventions: APCP/A06
This tell Point-Stat to use observations who's GRIB code is 61 with an
accumulation interval of 6-hours. Just substitute in whatever
accumulation interval you're evaluating.
Hope that helps.
Thanks,
John
On 07/21/2013 06:12 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>
> Sun Jul 21 18:12:35 2013: Request 62337 was acted upon.
> Transaction: Ticket created by erik.noble at nasa.gov
> Queue: met_help
> Subject: generating my own poly_mask and reading rain variable
for point_stat
> Owner: Nobody
> Requestors: erik.noble at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>
>
> Hi,
> 1. Is there a standard method of creating a poly-mask? My region is
over West Africa.
> 2. If I am reading both an observation (ascii2nc) file and plev-
wrfout file into point stat and they both contain the same variable of
precipitation, 'ACC_RAIN,'
> what do I change in point_stat configuration file? The example
documentation shows:
> 16 //
> 17 // Forecast and observation fields to be verified
> 18 //
> 19 fcst = {
> 20 wind_thresh = [ NA ];
> 21 message_type = [ "ADPUPA", "ADPSFC" ];
> 22
> 23 field = [
> 24 {
> 25 name = "TMP";
> 26 level = [ "P750-900" ];
> 27 cat_thresh = [ <=273, >273 ];
> 28 },
> 29
> 30 {
> 31 name = "UGRD";
> 32 level = [ "Z10" ];
> 33 cat_thresh = [ >=5 ];
> 34 },
> 35
> 36 {
> 37 name = "VGRD";
> 38 level = [ "Z10" ];
> 39 cat_thresh = [ >=5 ];
> 40 }
> 41 ];
> 42
> 43 };
> 44 obs = fcst;
> 45
>
> Is this saying that I should just replace the above text with the
following and that is it?
>
> 16 //
> 17 // Forecast and observation fields to be verified
> 18 //
> 19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
> 20 obs = fcst;
> 45
>
>
> Thank you.
> -Erik
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #62337] generating my own poly_mask and reading rain variable for point_stat
From: Noble, Erik U.[COLUMBIA UNIVERSITY]
Time: Tue Jul 23 14:20:13 2013
Hi John, thank you for answering both questions.
My mistake, I meant to say
"If I am reading both an observation (ascii2nc) file and plev-wrfout
file
into point-stat and they both contain daily accumulated precipitation,
but
the wrf file variable is called 'ACC_RAIN,'
what do I change in point_stat configuration file?"
UPP will not install on any of my computers here so I am stuck with
using
the p_interp program with my wrf-ARW files. I want to verify WRF daily
accumulated rain against 40 stations from a field campaign. So I have
to
combine the the RAINNC and RAINC variables in the wrfout file (TRAIN)
before the Pinterp-step, or avoid the Pinterp-step altogether. Either
way,
I still have a netcdf file similar to the original wrfout file. I
would
like to read the resulting netcdf file into pcp_combine. I am still
stuck
here because I have to change the metadata and global data. I call
this
variable ACC_RAIN.
Hopefully I can get my netcdf files to be read by Met.
-Erik
On 7/22/13 4:10 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
>Erik,
>
>To create a polyline mask, you simply create an ASCII file containing
a
>list of lat/lons that define the region of interest. For example,
take a
>look at METv4.1/data/poly/SWC.poly. The first line of
>the file specifies the name for the polyline. And the remaining
lines
>contain lat/lon values for the boundary points. The last point is
>connected back up to the first point to complete the area.
>The example is named "SWC" and contains 33 points. You need a
minimum of
>3 points to define a polyline, and there is no real maximum.
>
>You can use this ASCII file directly in the Point-Stat config file.
For
>example...
> poly = [ "MET_BASE/data/poly/SWC.poly" ];
>
>If your polyline contains a large number of points (a few hundred) or
you
>have many grid-points, the process of determining which grid points
are
>inside/outside the polyline can be slow. In that
>case, I'd suggest running your polyline through the gen_poly_mask
tool.
>It's described here:
>
>http://www.dtcenter.org/met/users/support/online_tutorial/METv4.0/gen_poly
>_mask/index.php
>
>Basically, you apply the polyline once to your domain to create a 0/1
>bitmap. Then you pass that to Point-Stat:
> poly = [ "output/of/gen_poly_mask.nc" ];
>
>I'm a bit confused about your second question. You say that your
>ASCII2NC output contains a variable named "ACC_RAIN". That shouldn't
be
>the case. Assuming it really is the output of ASCII2NC,
>here's how you'd set it up:
>
>fcst = {
> wind_thresh = [ NA ];
>
> field = [
> {
> name = "ACC_RAIN";
> level = [ "(*.*)" ];
> cat_thresh = [ >0 ]; // or whatever thresholds you'd like
> }
> ];
>};
>
>obs = {
> wind_thresh = [ NA ];
> message_type = [ "ADPSFC" ]; // I assume you've used the ADPSFC
>message type for precip
>
> field = [
> {
> name = "APCP";
> level = [ "A06" ]; // or whatever the accumulation
interval
>is
> cat_thresh = [ >0 ]; // or whatever thresholds you'd like
> }
> ];
>};
>
>The forecast field is NetCDF, so you tell Point-Stat the variable
>name/level info that way: ACC_RAIN(*,*)
>By convention, the observation field in Point-Stat is specified using
the
>GRIB conventions: APCP/A06
>This tell Point-Stat to use observations who's GRIB code is 61 with
an
>accumulation interval of 6-hours. Just substitute in whatever
>accumulation interval you're evaluating.
>
>Hope that helps.
>
>Thanks,
>John
>
>
>
>On 07/21/2013 06:12 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>>
>> Sun Jul 21 18:12:35 2013: Request 62337 was acted upon.
>> Transaction: Ticket created by erik.noble at nasa.gov
>> Queue: met_help
>> Subject: generating my own poly_mask and reading rain
variable
>>for point_stat
>> Owner: Nobody
>> Requestors: erik.noble at nasa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>
>>
>> Hi,
>> 1. Is there a standard method of creating a poly-mask? My region is
>>over West Africa.
>> 2. If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>file into point stat and they both contain the same variable of
>>precipitation, 'ACC_RAIN,'
>> what do I change in point_stat configuration file? The example
>>documentation shows:
>> 16 //
>> 17 // Forecast and observation fields to be verified
>> 18 //
>> 19 fcst = {
>> 20 wind_thresh = [ NA ];
>> 21 message_type = [ "ADPUPA", "ADPSFC" ];
>> 22
>> 23 field = [
>> 24 {
>> 25 name = "TMP";
>> 26 level = [ "P750-900" ];
>> 27 cat_thresh = [ <=273, >273 ];
>> 28 },
>> 29
>> 30 {
>> 31 name = "UGRD";
>> 32 level = [ "Z10" ];
>> 33 cat_thresh = [ >=5 ];
>> 34 },
>> 35
>> 36 {
>> 37 name = "VGRD";
>> 38 level = [ "Z10" ];
>> 39 cat_thresh = [ >=5 ];
>> 40 }
>> 41 ];
>> 42
>> 43 };
>> 44 obs = fcst;
>> 45
>>
>> Is this saying that I should just replace the above text with the
>>following and that is it?
>>
>> 16 //
>> 17 // Forecast and observation fields to be verified
>> 18 //
>> 19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
>> 20 obs = fcst;
>> 45
>>
>>
>> Thank you.
>> -Erik
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #62337] generating my own poly_mask and reading rain variable for point_stat
From: John Halley Gotway
Time: Wed Jul 24 15:46:57 2013
Hello Erik,
I read through your message and see that you're still working on
things. Do you have any questions in particular for me at this point?
Thanks,
John
On 07/23/2013 02:20 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>
> Hi John, thank you for answering both questions.
>
> My mistake, I meant to say
> "If I am reading both an observation (ascii2nc) file and plev-wrfout
file
> into point-stat and they both contain daily accumulated
precipitation, but
> the wrf file variable is called 'ACC_RAIN,'
> what do I change in point_stat configuration file?"
>
> UPP will not install on any of my computers here so I am stuck with
using
> the p_interp program with my wrf-ARW files. I want to verify WRF
daily
> accumulated rain against 40 stations from a field campaign. So I
have to
> combine the the RAINNC and RAINC variables in the wrfout file
(TRAIN)
> before the Pinterp-step, or avoid the Pinterp-step altogether.
Either way,
> I still have a netcdf file similar to the original wrfout file. I
would
> like to read the resulting netcdf file into pcp_combine. I am still
stuck
> here because I have to change the metadata and global data. I call
this
> variable ACC_RAIN.
>
> Hopefully I can get my netcdf files to be read by Met.
>
> -Erik
>
>
>
> On 7/22/13 4:10 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
>
>> Erik,
>>
>> To create a polyline mask, you simply create an ASCII file
containing a
>> list of lat/lons that define the region of interest. For example,
take a
>> look at METv4.1/data/poly/SWC.poly. The first line of
>> the file specifies the name for the polyline. And the remaining
lines
>> contain lat/lon values for the boundary points. The last point is
>> connected back up to the first point to complete the area.
>> The example is named "SWC" and contains 33 points. You need a
minimum of
>> 3 points to define a polyline, and there is no real maximum.
>>
>> You can use this ASCII file directly in the Point-Stat config file.
For
>> example...
>> poly = [ "MET_BASE/data/poly/SWC.poly" ];
>>
>> If your polyline contains a large number of points (a few hundred)
or you
>> have many grid-points, the process of determining which grid points
are
>> inside/outside the polyline can be slow. In that
>> case, I'd suggest running your polyline through the gen_poly_mask
tool.
>> It's described here:
>>
>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv4.0/gen_poly
>> _mask/index.php
>>
>> Basically, you apply the polyline once to your domain to create a
0/1
>> bitmap. Then you pass that to Point-Stat:
>> poly = [ "output/of/gen_poly_mask.nc" ];
>>
>> I'm a bit confused about your second question. You say that your
>> ASCII2NC output contains a variable named "ACC_RAIN". That
shouldn't be
>> the case. Assuming it really is the output of ASCII2NC,
>> here's how you'd set it up:
>>
>> fcst = {
>> wind_thresh = [ NA ];
>>
>> field = [
>> {
>> name = "ACC_RAIN";
>> level = [ "(*.*)" ];
>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>> }
>> ];
>> };
>>
>> obs = {
>> wind_thresh = [ NA ];
>> message_type = [ "ADPSFC" ]; // I assume you've used the ADPSFC
>> message type for precip
>>
>> field = [
>> {
>> name = "APCP";
>> level = [ "A06" ]; // or whatever the accumulation
interval
>> is
>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>> }
>> ];
>> };
>>
>> The forecast field is NetCDF, so you tell Point-Stat the variable
>> name/level info that way: ACC_RAIN(*,*)
>> By convention, the observation field in Point-Stat is specified
using the
>> GRIB conventions: APCP/A06
>> This tell Point-Stat to use observations who's GRIB code is 61 with
an
>> accumulation interval of 6-hours. Just substitute in whatever
>> accumulation interval you're evaluating.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>>
>>
>> On 07/21/2013 06:12 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>>>
>>> Sun Jul 21 18:12:35 2013: Request 62337 was acted upon.
>>> Transaction: Ticket created by erik.noble at nasa.gov
>>> Queue: met_help
>>> Subject: generating my own poly_mask and reading rain
variable
>>> for point_stat
>>> Owner: Nobody
>>> Requestors: erik.noble at nasa.gov
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>>
>>>
>>> Hi,
>>> 1. Is there a standard method of creating a poly-mask? My region
is
>>> over West Africa.
>>> 2. If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>> file into point stat and they both contain the same variable of
>>> precipitation, 'ACC_RAIN,'
>>> what do I change in point_stat configuration file? The example
>>> documentation shows:
>>> 16 //
>>> 17 // Forecast and observation fields to be verified
>>> 18 //
>>> 19 fcst = {
>>> 20 wind_thresh = [ NA ];
>>> 21 message_type = [ "ADPUPA", "ADPSFC" ];
>>> 22
>>> 23 field = [
>>> 24 {
>>> 25 name = "TMP";
>>> 26 level = [ "P750-900" ];
>>> 27 cat_thresh = [ <=273, >273 ];
>>> 28 },
>>> 29
>>> 30 {
>>> 31 name = "UGRD";
>>> 32 level = [ "Z10" ];
>>> 33 cat_thresh = [ >=5 ];
>>> 34 },
>>> 35
>>> 36 {
>>> 37 name = "VGRD";
>>> 38 level = [ "Z10" ];
>>> 39 cat_thresh = [ >=5 ];
>>> 40 }
>>> 41 ];
>>> 42
>>> 43 };
>>> 44 obs = fcst;
>>> 45
>>>
>>> Is this saying that I should just replace the above text with the
>>> following and that is it?
>>>
>>> 16 //
>>> 17 // Forecast and observation fields to be verified
>>> 18 //
>>> 19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
>>> 20 obs = fcst;
>>> 45
>>>
>>>
>>> Thank you.
>>> -Erik
>>>
>>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #62337] generating my own poly_mask and reading rain variable for point_stat
From: Noble, Erik U.[COLUMBIA UNIVERSITY]
Time: Fri Jul 26 17:22:39 2013
Hi.
Yes. I managed to install UPP and ran one WRF-ARW forecast of 12-days
through it. All the files are named WRFPRS_d01.#, where # is 00, 03,
06,..96.
I then made a test_pcp_combine script similar to the sample provided,
ran
it and resulted with an error: No exact match found for VarInfo
"APCP/A030000" in GRIB file
What needs to be changed in the forecast file if I am getting this
error?
> cat test_pcp_combine.sh
#!/bin/sh
export
TEST_OUT_DIR=/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/M
ET/out_erik
echo
echo "*** Running PCP-Combine to combine 3-hourly APCP accumulation
forecasts into a single 24 hour accumulation forecast ***"
../bin/pcp_combine \
20060902_000000 3 20060903_000000 24 \
${TEST_OUT_DIR}/pcp_combine/wrf32_fcst_24L_2006090300V_24A.nc \
-pcpdir ../data_erik/wrf32_postprd
/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/MET/scripts_pe
rsonal eunoble at dali04
> ./test_pcp_combine.sh
*** Running PCP-Combine to combine 3-hourly APCP accumulation
forecasts
into a single 24 hour accumulation forecast ***
DEBUG 1: [1] File ../data_erik/wrf32_postprd/WRFPRS_d01.24 matches
valid time of 20060903_000000
DEBUG 1: [2] File ../data_erik/wrf32_postprd/WRFPRS_d01.21 matches
valid time of 20060902_210000
DEBUG 1: [3] File ../data_erik/wrf32_postprd/WRFPRS_d01.18 matches
valid time of 20060902_180000
DEBUG 1: [4] File ../data_erik/wrf32_postprd/WRFPRS_d01.15 matches
valid time of 20060902_150000
DEBUG 1: [5] File ../data_erik/wrf32_postprd/WRFPRS_d01.12 matches
valid time of 20060902_120000
DEBUG 1: [6] File ../data_erik/wrf32_postprd/WRFPRS_d01.09 matches
valid time of 20060902_090000
DEBUG 1: [7] File ../data_erik/wrf32_postprd/WRFPRS_d01.06 matches
valid time of 20060902_060000
DEBUG 1: [8] File ../data_erik/wrf32_postprd/WRFPRS_d01.03 matches
valid time of 20060902_030000
DEBUG 1: [1] Reading input file:
../data_erik/wrf32_postprd/WRFPRS_d01.24
WARNING:
WARNING: MetGrib1DataFile::data_plane() -> No exact match found for
VarInfo "APCP/A030000" in GRIB file
"../data_erik/wrf32_postprd/WRFPRS_d01.24".
WARNING:
ERROR :
ERROR : get_field() -> can't get data plane from file
"../data_erik/wrf32_postprd/WRFPRS_d01.24"
ERROR :
****
Here are the variables in the UPP wrf file:
/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/MET/scripts_pe
rsonal eunoble at dali04
> ncl_filedump ../data_erik/wrf32_postprd/WRFPRS_d01.00.grb | grep
float
float PRES_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float PRES_GDS1_CBL ( g1_lat_0, g1_lon_1 )
float PRES_GDS1_CTL ( g1_lat_0, g1_lon_1 )
float PRES_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float PRMSL_GDS1_MSL ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_CBL ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_CTL ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_0DEG ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_TRO ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float HGT_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float HGT_GDS1_HTFL ( g1_lat_0, g1_lon_1 )
float HGT_GDS1_215 ( g1_lat_0, g1_lon_1 )
float TMP_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float TMP_GDS1_CTL ( g1_lat_0, g1_lon_1 )
float TMP_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float TMP_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float TMP_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float DPT_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float DPT_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float DPT_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float VIS_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float PLI_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float U_GRD_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float U_GRD_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float U_GRD_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float U_GRD_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float V_GRD_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float V_GRD_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float V_GRD_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float V_GRD_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float V_VEL_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float ABS_V_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float SPF_H_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float SPF_H_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float SPF_H_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
float SPF_H_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float R_H_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
float R_H_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
float R_H_GDS1_HYBL ( g1_lat_0, g1_lon_1 )
float P_WAT_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float P_WAT_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float EVP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float PRATE_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float A_PCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float NCPCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float ACPCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float WEASD_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float SNO_D_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float T_CDC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float CDCON_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float L_CDC_GDS1_LCY ( g1_lat_0, g1_lon_1 )
float M_CDC_GDS1_MCY ( g1_lat_0, g1_lon_1 )
float H_CDC_GDS1_HCY ( g1_lat_0, g1_lon_1 )
float SNO_L_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float WTMP_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float LAND_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float SFC_R_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float TSOIL_GDS1_DBLL ( g1_lat_0, g1_lon_1 )
float TSOIL_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
float SOIL_M_GDS1_DBLY ( g1_lat_0, g1_lon_1 )
float VEG_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float ICE_C_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float SNO_M_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float BRTMP_GDS1_NTAT ( g1_lat_0, g1_lon_1 )
float LHTFL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float SHTFL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float MSLET_GDS1_MSL ( g1_lat_0, g1_lon_1 )
float LFT_X_GDS1_ISBY ( g1_lat_0, g1_lon_1 )
float 4LFTX_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
float CRAIN_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CFRZR_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CICEPL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CSNOW_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float SOILW_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
float GFLUX_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CIN_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CIN_GDS1_SPDY ( lv_SPDY5, g1_lat_0, g1_lon_1 )
float CAPE_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CAPE_GDS1_SPDY ( lv_SPDY5, g1_lat_0, g1_lon_1 )
float NLAT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float ELON_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float GRMR_GDS1_ISBL ( g1_lat_0, g1_lon_1 )
float GUST_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float HLCY_GDS1_HTGY ( g1_lat_0, g1_lon_1 )
float DSWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float DLWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float MSTAV_GDS1_DBLY ( g1_lat_0, g1_lon_1 )
float USWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float ULWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float CPRAT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float HPBL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float PEVAP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float SSRUN_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
float SNOWC_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float FRICV_GDS1_SFC ( g1_lat_0, g1_lon_1 )
float TCOLW_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float TCOLI_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float TCOLR_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float TCOLS_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float TCOLC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float REFC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
float SOILL_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
float g1_lat_0 ( g1_lat_0 )
float g1_lon_1 ( g1_lon_1 )
Thank you.
-Erik
On 7/24/13 5:46 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
>Hello Erik,
>
>I read through your message and see that you're still working on
things.
>Do you have any questions in particular for me at this point?
>
>Thanks,
>John
>
>On 07/23/2013 02:20 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>
>> Hi John, thank you for answering both questions.
>>
>> My mistake, I meant to say
>> "If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>file
>> into point-stat and they both contain daily accumulated
precipitation,
>>but
>> the wrf file variable is called 'ACC_RAIN,'
>> what do I change in point_stat configuration file?"
>>
>> UPP will not install on any of my computers here so I am stuck with
>>using
>> the p_interp program with my wrf-ARW files. I want to verify WRF
daily
>> accumulated rain against 40 stations from a field campaign. So I
have to
>> combine the the RAINNC and RAINC variables in the wrfout file
(TRAIN)
>> before the Pinterp-step, or avoid the Pinterp-step altogether.
Either
>>way,
>> I still have a netcdf file similar to the original wrfout file. I
would
>> like to read the resulting netcdf file into pcp_combine. I am still
>>stuck
>> here because I have to change the metadata and global data. I call
this
>> variable ACC_RAIN.
>>
>> Hopefully I can get my netcdf files to be read by Met.
>>
>> -Erik
>>
>>
>>
>> On 7/22/13 4:10 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
>>wrote:
>>
>>> Erik,
>>>
>>> To create a polyline mask, you simply create an ASCII file
containing a
>>> list of lat/lons that define the region of interest. For example,
>>>take a
>>> look at METv4.1/data/poly/SWC.poly. The first line of
>>> the file specifies the name for the polyline. And the remaining
lines
>>> contain lat/lon values for the boundary points. The last point is
>>> connected back up to the first point to complete the area.
>>> The example is named "SWC" and contains 33 points. You need a
minimum
>>>of
>>> 3 points to define a polyline, and there is no real maximum.
>>>
>>> You can use this ASCII file directly in the Point-Stat config
file.
>>>For
>>> example...
>>> poly = [ "MET_BASE/data/poly/SWC.poly" ];
>>>
>>> If your polyline contains a large number of points (a few hundred)
or
>>>you
>>> have many grid-points, the process of determining which grid
points are
>>> inside/outside the polyline can be slow. In that
>>> case, I'd suggest running your polyline through the gen_poly_mask
tool.
>>> It's described here:
>>>
>>>
>>>http://www.dtcenter.org/met/users/support/online_tutorial/METv4.0/gen_po
>>>ly
>>> _mask/index.php
>>>
>>> Basically, you apply the polyline once to your domain to create a
0/1
>>> bitmap. Then you pass that to Point-Stat:
>>> poly = [ "output/of/gen_poly_mask.nc" ];
>>>
>>> I'm a bit confused about your second question. You say that your
>>> ASCII2NC output contains a variable named "ACC_RAIN". That
shouldn't
>>>be
>>> the case. Assuming it really is the output of ASCII2NC,
>>> here's how you'd set it up:
>>>
>>> fcst = {
>>> wind_thresh = [ NA ];
>>>
>>> field = [
>>> {
>>> name = "ACC_RAIN";
>>> level = [ "(*.*)" ];
>>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>>> }
>>> ];
>>> };
>>>
>>> obs = {
>>> wind_thresh = [ NA ];
>>> message_type = [ "ADPSFC" ]; // I assume you've used the
ADPSFC
>>> message type for precip
>>>
>>> field = [
>>> {
>>> name = "APCP";
>>> level = [ "A06" ]; // or whatever the accumulation
>>>interval
>>> is
>>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>>> }
>>> ];
>>> };
>>>
>>> The forecast field is NetCDF, so you tell Point-Stat the variable
>>> name/level info that way: ACC_RAIN(*,*)
>>> By convention, the observation field in Point-Stat is specified
using
>>>the
>>> GRIB conventions: APCP/A06
>>> This tell Point-Stat to use observations who's GRIB code is 61
with an
>>> accumulation interval of 6-hours. Just substitute in whatever
>>> accumulation interval you're evaluating.
>>>
>>> Hope that helps.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On 07/21/2013 06:12 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
>>>wrote:
>>>>
>>>> Sun Jul 21 18:12:35 2013: Request 62337 was acted upon.
>>>> Transaction: Ticket created by erik.noble at nasa.gov
>>>> Queue: met_help
>>>> Subject: generating my own poly_mask and reading rain
variable
>>>> for point_stat
>>>> Owner: Nobody
>>>> Requestors: erik.noble at nasa.gov
>>>> Status: new
>>>> Ticket <URL:
>>>>https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>>>
>>>>
>>>> Hi,
>>>> 1. Is there a standard method of creating a poly-mask? My region
is
>>>> over West Africa.
>>>> 2. If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>>> file into point stat and they both contain the same variable of
>>>> precipitation, 'ACC_RAIN,'
>>>> what do I change in point_stat configuration file? The example
>>>> documentation shows:
>>>> 16 //
>>>> 17 // Forecast and observation fields to be verified
>>>> 18 //
>>>> 19 fcst = {
>>>> 20 wind_thresh = [ NA ];
>>>> 21 message_type = [ "ADPUPA", "ADPSFC" ];
>>>> 22
>>>> 23 field = [
>>>> 24 {
>>>> 25 name = "TMP";
>>>> 26 level = [ "P750-900" ];
>>>> 27 cat_thresh = [ <=273, >273 ];
>>>> 28 },
>>>> 29
>>>> 30 {
>>>> 31 name = "UGRD";
>>>> 32 level = [ "Z10" ];
>>>> 33 cat_thresh = [ >=5 ];
>>>> 34 },
>>>> 35
>>>> 36 {
>>>> 37 name = "VGRD";
>>>> 38 level = [ "Z10" ];
>>>> 39 cat_thresh = [ >=5 ];
>>>> 40 }
>>>> 41 ];
>>>> 42
>>>> 43 };
>>>> 44 obs = fcst;
>>>> 45
>>>>
>>>> Is this saying that I should just replace the above text with the
>>>> following and that is it?
>>>>
>>>> 16 //
>>>> 17 // Forecast and observation fields to be verified
>>>> 18 //
>>>> 19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
>>>> 20 obs = fcst;
>>>> 45
>>>>
>>>>
>>>> Thank you.
>>>> -Erik
>>>>
>>>
>>
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #62337] generating my own poly_mask and reading rain variable for point_stat
From: John Halley Gotway
Time: Mon Jul 29 10:44:59 2013
Erik,
Since you're running WRF-ARW, I'm guessing that the GRIB files from
UPP contain "runtime" accumulations. That's the default way WRF-ARW
handles precip. That means that the 3-hour forecast contains
3-hours of precip, the 12-hour forecast contains 12-hours of precip,
24 has 24, and so on.
The default way that WRF-NMM handles precip is to dump the bucket for
3 or 6 hours (I can't remember which).
Since there's a difference in the way precip is handled, the MET
pcp_combine tool has the ability to add it up (for NMM) and subtract
it (for ARW).
For ARW, you'll likely need to perform subtraction commands to re-bin
the precip data. How to re-bin the data is driven by the availability
of your observations. For example, if you have 24-hour
observation data (00Z to 00Z), you'd need to re-bin your forecast data
into 24-hour chunks. Assuming your model is initialized at 00Z...
- The 24-hour forecast already has 24-hours of precip.
- The next 24-hours would be the 48-hour forecast minus the 24-hour
forecast.
- The next 24-hours would be the 72-hour forecast minus the 48-hour
forecast.
- And so on.
Here's an example of how you'd run pcp_combine for 48 minus 24:
METv4.1/bin/pcp_combine -subtract WRFPRS_d01.48 48 WRFPRS_d01.24
24 WRFPRS_d01_APCP_24_48.nc
This tells pcp_combine to extract 48 hours of accumulation from the
first file, 24 hours of accumulation from the second file, and
subtract them.
After you run pcp_combine, your APCP forecast files will all be in
NetCDF format rather than GRIB - except for the first 24-hour one.
For simplicity in scripting your calls to the other MET tools,
you may find it easier to get the 24-hour one into NetCDF as well. To
do that, you could run the 24-hour file as a "pass-through" like this:
METv4.1/bin/pcp_combine -add WRFPRS_d01.24 24
WRFPRS_d01_APCP_00_24.nc
This basically just extracts the 24-hour accumulation from the 24-hour
forecast file and writes it out in NetCDF.
Hope that helps clarify.
Thanks,
John
On 07/26/2013 05:22 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>
> Hi.
> Yes. I managed to install UPP and ran one WRF-ARW forecast of 12-
days
> through it. All the files are named WRFPRS_d01.#, where # is 00, 03,
> 06,..96.
>
> I then made a test_pcp_combine script similar to the sample
provided, ran
> it and resulted with an error: No exact match found for VarInfo
> "APCP/A030000" in GRIB file
>
>
> What needs to be changed in the forecast file if I am getting this
error?
>
>> cat test_pcp_combine.sh
> #!/bin/sh
> export
>
TEST_OUT_DIR=/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/M
> ET/out_erik
> echo
> echo "*** Running PCP-Combine to combine 3-hourly APCP
accumulation
> forecasts into a single 24 hour accumulation forecast ***"
> ../bin/pcp_combine \
> 20060902_000000 3 20060903_000000 24 \
> ${TEST_OUT_DIR}/pcp_combine/wrf32_fcst_24L_2006090300V_24A.nc \
> -pcpdir ../data_erik/wrf32_postprd
>
>
>
>
/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/MET/scripts_pe
> rsonal eunoble at dali04
> > ./test_pcp_combine.sh
>
> *** Running PCP-Combine to combine 3-hourly APCP accumulation
forecasts
> into a single 24 hour accumulation forecast ***
> DEBUG 1: [1] File ../data_erik/wrf32_postprd/WRFPRS_d01.24
matches
> valid time of 20060903_000000
> DEBUG 1: [2] File ../data_erik/wrf32_postprd/WRFPRS_d01.21
matches
> valid time of 20060902_210000
> DEBUG 1: [3] File ../data_erik/wrf32_postprd/WRFPRS_d01.18
matches
> valid time of 20060902_180000
> DEBUG 1: [4] File ../data_erik/wrf32_postprd/WRFPRS_d01.15
matches
> valid time of 20060902_150000
> DEBUG 1: [5] File ../data_erik/wrf32_postprd/WRFPRS_d01.12
matches
> valid time of 20060902_120000
> DEBUG 1: [6] File ../data_erik/wrf32_postprd/WRFPRS_d01.09
matches
> valid time of 20060902_090000
> DEBUG 1: [7] File ../data_erik/wrf32_postprd/WRFPRS_d01.06
matches
> valid time of 20060902_060000
> DEBUG 1: [8] File ../data_erik/wrf32_postprd/WRFPRS_d01.03
matches
> valid time of 20060902_030000
> DEBUG 1: [1] Reading input file:
> ../data_erik/wrf32_postprd/WRFPRS_d01.24
> WARNING:
> WARNING: MetGrib1DataFile::data_plane() -> No exact match found
for
> VarInfo "APCP/A030000" in GRIB file
> "../data_erik/wrf32_postprd/WRFPRS_d01.24".
> WARNING:
> ERROR :
> ERROR : get_field() -> can't get data plane from file
> "../data_erik/wrf32_postprd/WRFPRS_d01.24"
> ERROR :
>
>
> ****
> Here are the variables in the UPP wrf file:
>
/discover/nobackup/eunoble/myWorkDir/ALL_NEW/POST_PROCESSING/MET/scripts_pe
> rsonal eunoble at dali04
>> ncl_filedump ../data_erik/wrf32_postprd/WRFPRS_d01.00.grb | grep
float
> float PRES_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float PRES_GDS1_CBL ( g1_lat_0, g1_lon_1 )
> float PRES_GDS1_CTL ( g1_lat_0, g1_lon_1 )
> float PRES_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float PRMSL_GDS1_MSL ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_CBL ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_CTL ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_0DEG ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_TRO ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float HGT_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float HGT_GDS1_HTFL ( g1_lat_0, g1_lon_1 )
> float HGT_GDS1_215 ( g1_lat_0, g1_lon_1 )
> float TMP_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float TMP_GDS1_CTL ( g1_lat_0, g1_lon_1 )
> float TMP_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float TMP_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float TMP_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float DPT_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float DPT_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float DPT_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float VIS_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float PLI_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float U_GRD_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float U_GRD_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float U_GRD_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float U_GRD_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float V_GRD_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float V_GRD_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float V_GRD_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float V_GRD_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float V_VEL_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float ABS_V_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float SPF_H_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float SPF_H_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float SPF_H_GDS1_HYBL ( lv_HYBL2, g1_lat_0, g1_lon_1 )
> float SPF_H_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float R_H_GDS1_ISBL ( lv_ISBL3, g1_lat_0, g1_lon_1 )
> float R_H_GDS1_HTGL ( g1_lat_0, g1_lon_1 )
> float R_H_GDS1_HYBL ( g1_lat_0, g1_lon_1 )
> float P_WAT_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float P_WAT_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float EVP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float PRATE_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float A_PCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float NCPCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float ACPCP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float WEASD_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float SNO_D_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float T_CDC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float CDCON_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float L_CDC_GDS1_LCY ( g1_lat_0, g1_lon_1 )
> float M_CDC_GDS1_MCY ( g1_lat_0, g1_lon_1 )
> float H_CDC_GDS1_HCY ( g1_lat_0, g1_lon_1 )
> float SNO_L_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float WTMP_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float LAND_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float SFC_R_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float TSOIL_GDS1_DBLL ( g1_lat_0, g1_lon_1 )
> float TSOIL_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
> float SOIL_M_GDS1_DBLY ( g1_lat_0, g1_lon_1 )
> float VEG_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float ICE_C_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float SNO_M_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float BRTMP_GDS1_NTAT ( g1_lat_0, g1_lon_1 )
> float LHTFL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float SHTFL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float MSLET_GDS1_MSL ( g1_lat_0, g1_lon_1 )
> float LFT_X_GDS1_ISBY ( g1_lat_0, g1_lon_1 )
> float 4LFTX_GDS1_SPDY ( g1_lat_0, g1_lon_1 )
> float CRAIN_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CFRZR_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CICEPL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CSNOW_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float SOILW_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
> float GFLUX_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CIN_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CIN_GDS1_SPDY ( lv_SPDY5, g1_lat_0, g1_lon_1 )
> float CAPE_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CAPE_GDS1_SPDY ( lv_SPDY5, g1_lat_0, g1_lon_1 )
> float NLAT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float ELON_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float GRMR_GDS1_ISBL ( g1_lat_0, g1_lon_1 )
> float GUST_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float HLCY_GDS1_HTGY ( g1_lat_0, g1_lon_1 )
> float DSWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float DLWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float MSTAV_GDS1_DBLY ( g1_lat_0, g1_lon_1 )
> float USWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float ULWRF_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float CPRAT_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float HPBL_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float PEVAP_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float SSRUN_GDS1_SFC_acc ( g1_lat_0, g1_lon_1 )
> float SNOWC_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float FRICV_GDS1_SFC ( g1_lat_0, g1_lon_1 )
> float TCOLW_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float TCOLI_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float TCOLR_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float TCOLS_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float TCOLC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float REFC_GDS1_EATM ( g1_lat_0, g1_lon_1 )
> float SOILL_GDS1_DBLY ( lv_DBLY4, g1_lat_0, g1_lon_1 )
> float g1_lat_0 ( g1_lat_0 )
> float g1_lon_1 ( g1_lon_1 )
>
>
>
> Thank you.
> -Erik
>
> On 7/24/13 5:46 PM, "John Halley Gotway via RT" <met_help at ucar.edu>
wrote:
>
>> Hello Erik,
>>
>> I read through your message and see that you're still working on
things.
>> Do you have any questions in particular for me at this point?
>>
>> Thanks,
>> John
>>
>> On 07/23/2013 02:20 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via RT
wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>>
>>> Hi John, thank you for answering both questions.
>>>
>>> My mistake, I meant to say
>>> "If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>> file
>>> into point-stat and they both contain daily accumulated
precipitation,
>>> but
>>> the wrf file variable is called 'ACC_RAIN,'
>>> what do I change in point_stat configuration file?"
>>>
>>> UPP will not install on any of my computers here so I am stuck
with
>>> using
>>> the p_interp program with my wrf-ARW files. I want to verify WRF
daily
>>> accumulated rain against 40 stations from a field campaign. So I
have to
>>> combine the the RAINNC and RAINC variables in the wrfout file
(TRAIN)
>>> before the Pinterp-step, or avoid the Pinterp-step altogether.
Either
>>> way,
>>> I still have a netcdf file similar to the original wrfout file. I
would
>>> like to read the resulting netcdf file into pcp_combine. I am
still
>>> stuck
>>> here because I have to change the metadata and global data. I call
this
>>> variable ACC_RAIN.
>>>
>>> Hopefully I can get my netcdf files to be read by Met.
>>>
>>> -Erik
>>>
>>>
>>>
>>> On 7/22/13 4:10 PM, "John Halley Gotway via RT"
<met_help at ucar.edu>
>>> wrote:
>>>
>>>> Erik,
>>>>
>>>> To create a polyline mask, you simply create an ASCII file
containing a
>>>> list of lat/lons that define the region of interest. For
example,
>>>> take a
>>>> look at METv4.1/data/poly/SWC.poly. The first line of
>>>> the file specifies the name for the polyline. And the remaining
lines
>>>> contain lat/lon values for the boundary points. The last point
is
>>>> connected back up to the first point to complete the area.
>>>> The example is named "SWC" and contains 33 points. You need a
minimum
>>>> of
>>>> 3 points to define a polyline, and there is no real maximum.
>>>>
>>>> You can use this ASCII file directly in the Point-Stat config
file.
>>>> For
>>>> example...
>>>> poly = [ "MET_BASE/data/poly/SWC.poly" ];
>>>>
>>>> If your polyline contains a large number of points (a few
hundred) or
>>>> you
>>>> have many grid-points, the process of determining which grid
points are
>>>> inside/outside the polyline can be slow. In that
>>>> case, I'd suggest running your polyline through the gen_poly_mask
tool.
>>>> It's described here:
>>>>
>>>>
>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv4.0/gen_po
>>>> ly
>>>> _mask/index.php
>>>>
>>>> Basically, you apply the polyline once to your domain to create a
0/1
>>>> bitmap. Then you pass that to Point-Stat:
>>>> poly = [ "output/of/gen_poly_mask.nc" ];
>>>>
>>>> I'm a bit confused about your second question. You say that your
>>>> ASCII2NC output contains a variable named "ACC_RAIN". That
shouldn't
>>>> be
>>>> the case. Assuming it really is the output of ASCII2NC,
>>>> here's how you'd set it up:
>>>>
>>>> fcst = {
>>>> wind_thresh = [ NA ];
>>>>
>>>> field = [
>>>> {
>>>> name = "ACC_RAIN";
>>>> level = [ "(*.*)" ];
>>>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>>>> }
>>>> ];
>>>> };
>>>>
>>>> obs = {
>>>> wind_thresh = [ NA ];
>>>> message_type = [ "ADPSFC" ]; // I assume you've used the
ADPSFC
>>>> message type for precip
>>>>
>>>> field = [
>>>> {
>>>> name = "APCP";
>>>> level = [ "A06" ]; // or whatever the accumulation
>>>> interval
>>>> is
>>>> cat_thresh = [ >0 ]; // or whatever thresholds you'd
like
>>>> }
>>>> ];
>>>> };
>>>>
>>>> The forecast field is NetCDF, so you tell Point-Stat the variable
>>>> name/level info that way: ACC_RAIN(*,*)
>>>> By convention, the observation field in Point-Stat is specified
using
>>>> the
>>>> GRIB conventions: APCP/A06
>>>> This tell Point-Stat to use observations who's GRIB code is 61
with an
>>>> accumulation interval of 6-hours. Just substitute in whatever
>>>> accumulation interval you're evaluating.
>>>>
>>>> Hope that helps.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>> On 07/21/2013 06:12 PM, Noble, Erik U.[COLUMBIA UNIVERSITY] via
RT
>>>> wrote:
>>>>>
>>>>> Sun Jul 21 18:12:35 2013: Request 62337 was acted upon.
>>>>> Transaction: Ticket created by erik.noble at nasa.gov
>>>>> Queue: met_help
>>>>> Subject: generating my own poly_mask and reading rain
variable
>>>>> for point_stat
>>>>> Owner: Nobody
>>>>> Requestors: erik.noble at nasa.gov
>>>>> Status: new
>>>>> Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=62337 >
>>>>>
>>>>>
>>>>> Hi,
>>>>> 1. Is there a standard method of creating a poly-mask? My region
is
>>>>> over West Africa.
>>>>> 2. If I am reading both an observation (ascii2nc) file and plev-
wrfout
>>>>> file into point stat and they both contain the same variable of
>>>>> precipitation, 'ACC_RAIN,'
>>>>> what do I change in point_stat configuration file? The example
>>>>> documentation shows:
>>>>> 16 //
>>>>> 17 // Forecast and observation fields to be verified
>>>>> 18 //
>>>>> 19 fcst = {
>>>>> 20 wind_thresh = [ NA ];
>>>>> 21 message_type = [ "ADPUPA", "ADPSFC" ];
>>>>> 22
>>>>> 23 field = [
>>>>> 24 {
>>>>> 25 name = "TMP";
>>>>> 26 level = [ "P750-900" ];
>>>>> 27 cat_thresh = [ <=273, >273 ];
>>>>> 28 },
>>>>> 29
>>>>> 30 {
>>>>> 31 name = "UGRD";
>>>>> 32 level = [ "Z10" ];
>>>>> 33 cat_thresh = [ >=5 ];
>>>>> 34 },
>>>>> 35
>>>>> 36 {
>>>>> 37 name = "VGRD";
>>>>> 38 level = [ "Z10" ];
>>>>> 39 cat_thresh = [ >=5 ];
>>>>> 40 }
>>>>> 41 ];
>>>>> 42
>>>>> 43 };
>>>>> 44 obs = fcst;
>>>>> 45
>>>>>
>>>>> Is this saying that I should just replace the above text with
the
>>>>> following and that is it?
>>>>>
>>>>> 16 //
>>>>> 17 // Forecast and observation fields to be verified
>>>>> 18 //
>>>>> 19 fcst_field[] = [ "ACC_RAIN(0,*,*)" ];
>>>>> 20 obs = fcst;
>>>>> 45
>>>>>
>>>>>
>>>>> Thank you.
>>>>> -Erik
>>>>>
>>>>
>>>
>>>
>>
>
>
------------------------------------------------
More information about the Met_help
mailing list