[Met_help] [rt.rap.ucar.edu #90730] History for Questions about point_stat
John Halley Gotway via RT
met_help at ucar.edu
Tue Aug 6 11:24:57 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I'm trying to use python embedding within point stat to verify a model field
of wind at 10 m using raobs whose positions are in pressure. Is there a
value in the config file that I need to set so that point_Stat knows to
interpolate to a common height between meter and pressure? Because right now
I'm getting 0 matched pairs when I run point_stat
Justin
Justin Tsu
Marine Meteorology Division
Data Assimilation/Mesoscale Modeling
Building 704 Room 212
Naval Research Laboratory, Code 7531
7 Grace Hopper Avenue
Monterey, CA 93943-5502
Ph. (831) 656-4111
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Questions about point_stat
From: Minna Win
Time: Fri Jun 21 09:10:54 2019
Hello,
It appears that you have questions about setting up your point-stat
configuration file. This ticket is being assigned to John Halley
Gotway,
our resident expert on point stat. Please allow 1-3 days for a
response.
Thank you for your question.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 303-497-8401
On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> Queue: met_help
> Subject: Questions about point_stat
> Owner: Nobody
> Requestors: justin.tsu at nrlmry.navy.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
>
> Hello,
>
>
>
> I'm trying to use python embedding within point stat to verify a
model
> field
> of wind at 10 m using raobs whose positions are in pressure. Is
there a
> value in the config file that I need to set so that point_Stat knows
to
> interpolate to a common height between meter and pressure? Because
right
> now
> I'm getting 0 matched pairs when I run point_stat
>
>
>
> Justin
>
>
>
> Justin Tsu
>
> Marine Meteorology Division
>
> Data Assimilation/Mesoscale Modeling
>
> Building 704 Room 212
>
> Naval Research Laboratory, Code 7531
>
> 7 Grace Hopper Avenue
>
> Monterey, CA 93943-5502
>
>
>
> Ph. (831) 656-4111
>
>
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: John Halley Gotway
Time: Fri Jun 21 13:59:03 2019
Hi Justin,
I see you have a question about using Python embedding in Point-Stat.
So
you're passing a single forecast field of 10 m wind to Point-Stat and
want
to compare it to point observations. But your point observations are
in
pressure, not height.
Here's some information which applies to this situation...
First, Point-Stat does not do any conversion of pressure to height for
you,
or vice versa. However, typically point observations include both a
height
above ground and a pressure level. For example, the ascii2nc tool in
MET
can read a simple 11-column ascii point observation format:
The "met_point" ASCII format consists of 11 columns:
Message_Type Station_ID Valid_Time(YYYYMMDD_HHMMSS)
Lat(Deg North) Lon(Deg East) Elevation(msl)
Var_Name(or GRIB_Code) Level Height(msl or agl)
QC_String Observation_Value
For a sounding, the pressure level is listed in the "Level" column and
the
height is listed in the "Height" column. Take a look at the point
observations you're using to see if you have both height and pressure
listed.
Second, typically, 2-m temperature and 10-m winds are considered to be
forecasts at the "surface". Adopting the logic from NCEP's
verification
package, on which MET was originally based, the matching for surface
fields
is done by the message type, not the actual vertical level. For
example,
let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
and you're verifying it against the ADPSFC message type (land surface
observations). Point-Stat doesn't actually check the height of the
observation to make sure it's exactly 2. Instead, all ADPSFC
observations
are automatically used since they are assumed to live at the surface.
Take
a look at the PointStatConfig file, the "message_type_group" map's
entry
for "SURFACE" defines the message types for which this logic should be
applied:
//
// Mapping of message type group name to comma-separated list of
values.
//
message_type_group_map = [
{ key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET"; },
{ key = "ANYAIR"; val = "AIRCAR,AIRCFT"; },
{ key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
{ key = "ONLYSF"; val = "ADPSFC,SFCSHP"; },
{ key = "LANDSF"; val = "ADPSFC,MSONET"; },
{ key = "WATERSF"; val = "SFCSHP"; }
];
Third, there are many ways to configure Point-Stat to control what
range of
vertical levels are used in the verification, both in the forecast and
observation data sources. For example, let's say you're verifying
500mb
temperature against upper-air observations. Here's 3 ways you could
configure it:
(1) Single forecast field versus single observation level:
fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
obs = fcst;
(2) Single forecast field versus range of observation levels:
fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
(3) Range of forecast fields versus range of observation levels:
fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
In (1) and (2), we do not vertical interpolation of the forecast data
since
you've only requested a single level. In (3), we'll read data for
400,
500, and 600 mb levels, but only use obs falling between 450 and 550.
For
each obs, we'll vertically interpolate the forecast values from the
levels
above/below it to the actual pressure level of the obs.
So lots of configuration options.
If that answers your question, then great. If not, you could send me
some
sample data with a description of what you're trying to do, and I can
run
it here.
Thanks,
John Halley Gotway
On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> Queue: met_help
> Subject: Questions about point_stat
> Owner: Nobody
> Requestors: justin.tsu at nrlmry.navy.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
>
> Hello,
>
>
>
> I'm trying to use python embedding within point stat to verify a
model
> field
> of wind at 10 m using raobs whose positions are in pressure. Is
there a
> value in the config file that I need to set so that point_Stat knows
to
> interpolate to a common height between meter and pressure? Because
right
> now
> I'm getting 0 matched pairs when I run point_stat
>
>
>
> Justin
>
>
>
> Justin Tsu
>
> Marine Meteorology Division
>
> Data Assimilation/Mesoscale Modeling
>
> Building 704 Room 212
>
> Naval Research Laboratory, Code 7531
>
> 7 Grace Hopper Avenue
>
> Monterey, CA 93943-5502
>
>
>
> Ph. (831) 656-4111
>
>
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: Tsu, Mr. Justin
Time: Fri Jul 12 14:12:59 2019
Hi John,
Thank you for your descriptive response and apologies for the delay.
I got
caught up in some other work.
I am investigating the second method you proposed which was to use
ADPSFC.
Couple questions here:
1. Does ADPSFC have any meaning other than to use it as a reference to
link
obs and fcst to the same message group type (SURFACE)?
2. Is ADPSFC an ob only designation of message_type? Or am I supposed
to
assign message_type ADPSFC to both obs and fcst dictionaries?
I ended up testing message_type=ADPSFC for both obs and fcst to test
it out:
73 fcst = {
74
75
76 field = [
77 {
78 name = "/users/tsu/MET/work/read_NRL_binary.py
uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
79 message_type = ["ADPSFC"];
80 }
81
82 ];
83
84 }
85
86 obs = {
87 field = [
88 {
89 file_type = NETCDF_NCCF;
90 name = "ws";
91 level = ["P975-P1000"];
92 message_type = ["ADPSFC"];
93 }
94 ];
95 }
If I am understanding your message correctly, if I set the message
types of
both fcst and obs to ADPSFC, point_stat will ignore the
height/level/elevation
columns of my observations and my forecast field and just compare as
is with
necessary horizontal interpolation. Is this correct?
Either way, running it this way gives me 0 matched pairs...
point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
DEBUG 1: Default Config File:
/software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
DEBUG 1: User Config File: config.rc
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=99166301
DEBUG 1: Forecast File: PYTHON_NUMPY
DEBUG 1: Observation File: sfc_2019042612.nc
Input File:
'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
Data Shape: (73, 75)
Data Type: dtype('float64')
Data Range: -5.4485907554626465 to 11.497947692871094
Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
'20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere': 'N',
'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS Test
Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx': 75,
'ny': 73,
'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0}, 'name':
'uuwind',
'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum': '00'}
DEBUG 2:
DEBUG
2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for uuwind/zht_000010.
DEBUG 3: Use the forecast grid.
DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny: 73
Lat_LL:
30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone: 0.716
Bx:
283.3939 By: -23.3975
DEBUG 2: Processing masking regions.
DEBUG 3: Processing grid mask: FULL
DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0 climatology
mean
levels, and 0 climatology standard deviation levels.
DEBUG 2:
DEBUG
2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 14080 observations from 1800 messages.
DEBUG 2:
DEBUG
2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for observation
type
ADPSFC, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 1565
DEBUG 3: Rejected: level mismatch = 0
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 0
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
DEBUG 2:
DEBUG
2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V_cnt.txt
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, June 21, 2019 12:59 PM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
Hi Justin,
I see you have a question about using Python embedding in Point-Stat.
So
you're passing a single forecast field of 10 m wind to Point-Stat and
want
to compare it to point observations. But your point observations are
in
pressure, not height.
Here's some information which applies to this situation...
First, Point-Stat does not do any conversion of pressure to height for
you,
or vice versa. However, typically point observations include both a
height
above ground and a pressure level. For example, the ascii2nc tool in
MET
can read a simple 11-column ascii point observation format:
The "met_point" ASCII format consists of 11 columns:
Message_Type Station_ID Valid_Time(YYYYMMDD_HHMMSS)
Lat(Deg North) Lon(Deg East) Elevation(msl)
Var_Name(or GRIB_Code) Level Height(msl or agl)
QC_String Observation_Value
For a sounding, the pressure level is listed in the "Level" column and
the
height is listed in the "Height" column. Take a look at the point
observations you're using to see if you have both height and pressure
listed.
Second, typically, 2-m temperature and 10-m winds are considered to be
forecasts at the "surface". Adopting the logic from NCEP's
verification
package, on which MET was originally based, the matching for surface
fields
is done by the message type, not the actual vertical level. For
example,
let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
and you're verifying it against the ADPSFC message type (land surface
observations). Point-Stat doesn't actually check the height of the
observation to make sure it's exactly 2. Instead, all ADPSFC
observations
are automatically used since they are assumed to live at the surface.
Take
a look at the PointStatConfig file, the "message_type_group" map's
entry
for "SURFACE" defines the message types for which this logic should be
applied:
//
// Mapping of message type group name to comma-separated list of
values.
//
message_type_group_map = [
{ key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET"; },
{ key = "ANYAIR"; val = "AIRCAR,AIRCFT"; },
{ key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
{ key = "ONLYSF"; val = "ADPSFC,SFCSHP"; },
{ key = "LANDSF"; val = "ADPSFC,MSONET"; },
{ key = "WATERSF"; val = "SFCSHP"; }
];
Third, there are many ways to configure Point-Stat to control what
range of
vertical levels are used in the verification, both in the forecast and
observation data sources. For example, let's say you're verifying
500mb
temperature against upper-air observations. Here's 3 ways you could
configure it:
(1) Single forecast field versus single observation level:
fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
obs = fcst;
(2) Single forecast field versus range of observation levels:
fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
(3) Range of forecast fields versus range of observation levels:
fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
In (1) and (2), we do not vertical interpolation of the forecast data
since
you've only requested a single level. In (3), we'll read data for
400,
500, and 600 mb levels, but only use obs falling between 450 and 550.
For
each obs, we'll vertically interpolate the forecast values from the
levels
above/below it to the actual pressure level of the obs.
So lots of configuration options.
If that answers your question, then great. If not, you could send me
some
sample data with a description of what you're trying to do, and I can
run
it here.
Thanks,
John Halley Gotway
On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> Queue: met_help
> Subject: Questions about point_stat
> Owner: Nobody
> Requestors: justin.tsu at nrlmry.navy.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
>
> Hello,
>
>
>
> I'm trying to use python embedding within point stat to verify a
model
> field
> of wind at 10 m using raobs whose positions are in pressure. Is
there a
> value in the config file that I need to set so that point_Stat knows
to
> interpolate to a common height between meter and pressure? Because
right
> now
> I'm getting 0 matched pairs when I run point_stat
>
>
>
> Justin
>
>
>
> Justin Tsu
>
> Marine Meteorology Division
>
> Data Assimilation/Mesoscale Modeling
>
> Building 704 Room 212
>
> Naval Research Laboratory, Code 7531
>
> 7 Grace Hopper Avenue
>
> Monterey, CA 93943-5502
>
>
>
> Ph. (831) 656-4111
>
>
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: John Halley Gotway
Time: Fri Jul 12 16:30:05 2019
Justin,
The message_type is an attribute of the observations. So it only
needs to
appear in the "obs" dictionary. But having it in the "fcst"
dictionary as
well should have no effect. The ADPSFC message type indicates to MET
that
the observations occur at the surface... that's their special meaning.
Yes, looking at the counts I see that most are being discard because
they
don't match the requested message type (12515) and others are off your
model domain (1565):
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: off the grid = 1565
So you just need to take a look at how the point observations are
encoded
in the point observation NetCDF file:
sfc_2019042612.nc
If you have access to R, you can dump those to ascii which is more
readable, by running:
Rscript /software/depot/met/met-
8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
Do you actually have ADPSFC message types in there? And if so, do
they
actually fall inside your model domain?
MET's plot_point_obs tool can be helpful in answering these questions,
but
since you're using Python embedding, that complicates things a bit.
Let me know what additional questions you have.
Thanks,
John
On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Hi John,
>
> Thank you for your descriptive response and apologies for the delay.
I
> got
> caught up in some other work.
>
> I am investigating the second method you proposed which was to use
ADPSFC.
> Couple questions here:
>
> 1. Does ADPSFC have any meaning other than to use it as a reference
to
> link
> obs and fcst to the same message group type (SURFACE)?
>
> 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed to
> assign message_type ADPSFC to both obs and fcst dictionaries?
>
> I ended up testing message_type=ADPSFC for both obs and fcst to test
it
> out:
>
> 73 fcst = {
> 74
> 75
> 76 field = [
> 77 {
> 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> 79 message_type = ["ADPSFC"];
> 80 }
> 81
> 82 ];
> 83
> 84 }
> 85
> 86 obs = {
> 87 field = [
> 88 {
> 89 file_type = NETCDF_NCCF;
> 90 name = "ws";
> 91 level = ["P975-P1000"];
> 92 message_type = ["ADPSFC"];
> 93 }
> 94 ];
> 95 }
>
> If I am understanding your message correctly, if I set the message
types
> of
> both fcst and obs to ADPSFC, point_stat will ignore the
> height/level/elevation
> columns of my observations and my forecast field and just compare as
is
> with
> necessary horizontal interpolation. Is this correct?
>
> Either way, running it this way gives me 0 matched pairs...
>
> point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> DEBUG 1: Default Config File:
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config.rc
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=99166301
> DEBUG 1: Forecast File: PYTHON_NUMPY
> DEBUG 1: Observation File: sfc_2019042612.nc
> Input File:
> 'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> Data Shape: (73, 75)
> Data Type: dtype('float64')
> Data Range: -5.4485907554626465 to 11.497947692871094
> Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
> '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere': 'N',
> 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> Test
> Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx': 75,
'ny':
> 73,
> 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0}, 'name':
> 'uuwind',
> 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for uuwind/zht_000010.
> DEBUG 3: Use the forecast grid.
> DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny:
73
> Lat_LL:
> 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716 Bx:
> 283.3939 By: -23.3975
> DEBUG 2: Processing masking regions.
> DEBUG 3: Processing grid mask: FULL
> DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology mean
> levels, and 0 climatology standard deviation levels.
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Searching 14080 observations from 1800 messages.
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for observation
type
> ADPSFC, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 1565
> DEBUG 3: Rejected: level mismatch = 0
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V_cnt.txt
>
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, June 21, 2019 12:59 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Hi Justin,
>
> I see you have a question about using Python embedding in Point-
Stat. So
> you're passing a single forecast field of 10 m wind to Point-Stat
and want
> to compare it to point observations. But your point observations
are in
> pressure, not height.
>
> Here's some information which applies to this situation...
>
> First, Point-Stat does not do any conversion of pressure to height
for you,
> or vice versa. However, typically point observations include both a
height
> above ground and a pressure level. For example, the ascii2nc tool
in MET
> can read a simple 11-column ascii point observation format:
> The "met_point" ASCII format consists of 11 columns:
> Message_Type Station_ID Valid_Time(YYYYMMDD_HHMMSS)
> Lat(Deg North) Lon(Deg East) Elevation(msl)
> Var_Name(or GRIB_Code) Level Height(msl or agl)
> QC_String Observation_Value
> For a sounding, the pressure level is listed in the "Level" column
and the
> height is listed in the "Height" column. Take a look at the point
> observations you're using to see if you have both height and
pressure
> listed.
>
> Second, typically, 2-m temperature and 10-m winds are considered to
be
> forecasts at the "surface". Adopting the logic from NCEP's
verification
> package, on which MET was originally based, the matching for surface
fields
> is done by the message type, not the actual vertical level. For
example,
> let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
> and you're verifying it against the ADPSFC message type (land
surface
> observations). Point-Stat doesn't actually check the height of the
> observation to make sure it's exactly 2. Instead, all ADPSFC
observations
> are automatically used since they are assumed to live at the
surface. Take
> a look at the PointStatConfig file, the "message_type_group" map's
entry
> for "SURFACE" defines the message types for which this logic should
be
> applied:
>
> //
> // Mapping of message type group name to comma-separated list of
values.
> //
> message_type_group_map = [
> { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET"; },
> { key = "ANYAIR"; val = "AIRCAR,AIRCFT"; },
> { key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
> { key = "ONLYSF"; val = "ADPSFC,SFCSHP"; },
> { key = "LANDSF"; val = "ADPSFC,MSONET"; },
> { key = "WATERSF"; val = "SFCSHP"; }
> ];
>
> Third, there are many ways to configure Point-Stat to control what
range of
> vertical levels are used in the verification, both in the forecast
and
> observation data sources. For example, let's say you're verifying
500mb
> temperature against upper-air observations. Here's 3 ways you could
> configure it:
>
> (1) Single forecast field versus single observation level:
> fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> obs = fcst;
>
> (2) Single forecast field versus range of observation levels:
> fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
>
> (3) Range of forecast fields versus range of observation levels:
> fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
>
> In (1) and (2), we do not vertical interpolation of the forecast
data since
> you've only requested a single level. In (3), we'll read data for
400,
> 500, and 600 mb levels, but only use obs falling between 450 and
550. For
> each obs, we'll vertically interpolate the forecast values from the
levels
> above/below it to the actual pressure level of the obs.
>
> So lots of configuration options.
>
> If that answers your question, then great. If not, you could send
me some
> sample data with a description of what you're trying to do, and I
can run
> it here.
>
> Thanks,
> John Halley Gotway
>
>
> On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > Queue: met_help
> > Subject: Questions about point_stat
> > Owner: Nobody
> > Requestors: justin.tsu at nrlmry.navy.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> >
> > Hello,
> >
> >
> >
> > I'm trying to use python embedding within point stat to verify a
model
> > field
> > of wind at 10 m using raobs whose positions are in pressure. Is
there a
> > value in the config file that I need to set so that point_Stat
knows to
> > interpolate to a common height between meter and pressure? Because
right
> > now
> > I'm getting 0 matched pairs when I run point_stat
> >
> >
> >
> > Justin
> >
> >
> >
> > Justin Tsu
> >
> > Marine Meteorology Division
> >
> > Data Assimilation/Mesoscale Modeling
> >
> > Building 704 Room 212
> >
> > Naval Research Laboratory, Code 7531
> >
> > 7 Grace Hopper Avenue
> >
> > Monterey, CA 93943-5502
> >
> >
> >
> > Ph. (831) 656-4111
> >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: Tsu, Mr. Justin
Time: Fri Jul 12 17:05:19 2019
Thanks John,
My message type in my observation file is 'SYNOP' so I've changed the
message_type and message_group_type to SYNOP (SURFACE=SYNOP). Still
getting 0
matched pairs.
Can you explain to me how point_stat uses the configuration file's
definition
of message_type=surface to compare with the forecast? You've already
explained to me that by providing point_Stat with a zht_10 UWIND
field,
point_Stat automatically considers this surface data; hence, my
forecast is
at the surface. Now, when I put message_type=SYNOP (and
SURFACE={SYNOP} in
message_group_type), does point_stat now consider my obs to be at the
surface?
At this point, are my obs and fcst at the same vertical level in the
MET
domain?
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, July 12, 2019 3:30 PM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
Justin,
The message_type is an attribute of the observations. So it only
needs to
appear in the "obs" dictionary. But having it in the "fcst"
dictionary as
well should have no effect. The ADPSFC message type indicates to MET
that
the observations occur at the surface... that's their special meaning.
Yes, looking at the counts I see that most are being discard because
they
don't match the requested message type (12515) and others are off your
model domain (1565):
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: off the grid = 1565
So you just need to take a look at how the point observations are
encoded
in the point observation NetCDF file:
sfc_2019042612.nc
If you have access to R, you can dump those to ascii which is more
readable, by running:
Rscript /software/depot/met/met-
8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
Do you actually have ADPSFC message types in there? And if so, do
they
actually fall inside your model domain?
MET's plot_point_obs tool can be helpful in answering these questions,
but
since you're using Python embedding, that complicates things a bit.
Let me know what additional questions you have.
Thanks,
John
On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Hi John,
>
> Thank you for your descriptive response and apologies for the delay.
I
> got
> caught up in some other work.
>
> I am investigating the second method you proposed which was to use
ADPSFC.
> Couple questions here:
>
> 1. Does ADPSFC have any meaning other than to use it as a reference
to
> link
> obs and fcst to the same message group type (SURFACE)?
>
> 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed to
> assign message_type ADPSFC to both obs and fcst dictionaries?
>
> I ended up testing message_type=ADPSFC for both obs and fcst to test
it
> out:
>
> 73 fcst = {
> 74
> 75
> 76 field = [
> 77 {
> 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> 79 message_type = ["ADPSFC"];
> 80 }
> 81
> 82 ];
> 83
> 84 }
> 85
> 86 obs = {
> 87 field = [
> 88 {
> 89 file_type = NETCDF_NCCF;
> 90 name = "ws";
> 91 level = ["P975-P1000"];
> 92 message_type = ["ADPSFC"];
> 93 }
> 94 ];
> 95 }
>
> If I am understanding your message correctly, if I set the message
types
> of
> both fcst and obs to ADPSFC, point_stat will ignore the
> height/level/elevation
> columns of my observations and my forecast field and just compare as
is
> with
> necessary horizontal interpolation. Is this correct?
>
> Either way, running it this way gives me 0 matched pairs...
>
> point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> DEBUG 1: Default Config File:
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config.rc
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=99166301
> DEBUG 1: Forecast File: PYTHON_NUMPY
> DEBUG 1: Observation File: sfc_2019042612.nc
> Input File:
> 'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> Data Shape: (73, 75)
> Data Type: dtype('float64')
> Data Range: -5.4485907554626465 to 11.497947692871094
> Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
> '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere': 'N',
> 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> Test
> Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx': 75,
'ny':
> 73,
> 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0}, 'name':
> 'uuwind',
> 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for uuwind/zht_000010.
> DEBUG 3: Use the forecast grid.
> DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny:
73
> Lat_LL:
> 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716 Bx:
> 283.3939 By: -23.3975
> DEBUG 2: Processing masking regions.
> DEBUG 3: Processing grid mask: FULL
> DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology mean
> levels, and 0 climatology standard deviation levels.
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Searching 14080 observations from 1800 messages.
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for observation
type
> ADPSFC, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 1565
> DEBUG 3: Rejected: level mismatch = 0
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
> DEBUG 2:
> DEBUG
> 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V_cnt.txt
>
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, June 21, 2019 12:59 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Hi Justin,
>
> I see you have a question about using Python embedding in Point-
Stat. So
> you're passing a single forecast field of 10 m wind to Point-Stat
and want
> to compare it to point observations. But your point observations
are in
> pressure, not height.
>
> Here's some information which applies to this situation...
>
> First, Point-Stat does not do any conversion of pressure to height
for you,
> or vice versa. However, typically point observations include both a
height
> above ground and a pressure level. For example, the ascii2nc tool
in MET
> can read a simple 11-column ascii point observation format:
> The "met_point" ASCII format consists of 11 columns:
> Message_Type Station_ID Valid_Time(YYYYMMDD_HHMMSS)
> Lat(Deg North) Lon(Deg East) Elevation(msl)
> Var_Name(or GRIB_Code) Level Height(msl or agl)
> QC_String Observation_Value
> For a sounding, the pressure level is listed in the "Level" column
and the
> height is listed in the "Height" column. Take a look at the point
> observations you're using to see if you have both height and
pressure
> listed.
>
> Second, typically, 2-m temperature and 10-m winds are considered to
be
> forecasts at the "surface". Adopting the logic from NCEP's
verification
> package, on which MET was originally based, the matching for surface
fields
> is done by the message type, not the actual vertical level. For
example,
> let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
> and you're verifying it against the ADPSFC message type (land
surface
> observations). Point-Stat doesn't actually check the height of the
> observation to make sure it's exactly 2. Instead, all ADPSFC
observations
> are automatically used since they are assumed to live at the
surface. Take
> a look at the PointStatConfig file, the "message_type_group" map's
entry
> for "SURFACE" defines the message types for which this logic should
be
> applied:
>
> //
> // Mapping of message type group name to comma-separated list of
values.
> //
> message_type_group_map = [
> { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET"; },
> { key = "ANYAIR"; val = "AIRCAR,AIRCFT"; },
> { key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
> { key = "ONLYSF"; val = "ADPSFC,SFCSHP"; },
> { key = "LANDSF"; val = "ADPSFC,MSONET"; },
> { key = "WATERSF"; val = "SFCSHP"; }
> ];
>
> Third, there are many ways to configure Point-Stat to control what
range of
> vertical levels are used in the verification, both in the forecast
and
> observation data sources. For example, let's say you're verifying
500mb
> temperature against upper-air observations. Here's 3 ways you could
> configure it:
>
> (1) Single forecast field versus single observation level:
> fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> obs = fcst;
>
> (2) Single forecast field versus range of observation levels:
> fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
>
> (3) Range of forecast fields versus range of observation levels:
> fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
>
> In (1) and (2), we do not vertical interpolation of the forecast
data since
> you've only requested a single level. In (3), we'll read data for
400,
> 500, and 600 mb levels, but only use obs falling between 450 and
550. For
> each obs, we'll vertically interpolate the forecast values from the
levels
> above/below it to the actual pressure level of the obs.
>
> So lots of configuration options.
>
> If that answers your question, then great. If not, you could send
me some
> sample data with a description of what you're trying to do, and I
can run
> it here.
>
> Thanks,
> John Halley Gotway
>
>
> On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > Queue: met_help
> > Subject: Questions about point_stat
> > Owner: Nobody
> > Requestors: justin.tsu at nrlmry.navy.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> >
> > Hello,
> >
> >
> >
> > I'm trying to use python embedding within point stat to verify a
model
> > field
> > of wind at 10 m using raobs whose positions are in pressure. Is
there a
> > value in the config file that I need to set so that point_Stat
knows to
> > interpolate to a common height between meter and pressure? Because
right
> > now
> > I'm getting 0 matched pairs when I run point_stat
> >
> >
> >
> > Justin
> >
> >
> >
> > Justin Tsu
> >
> > Marine Meteorology Division
> >
> > Data Assimilation/Mesoscale Modeling
> >
> > Building 704 Room 212
> >
> > Naval Research Laboratory, Code 7531
> >
> > 7 Grace Hopper Avenue
> >
> > Monterey, CA 93943-5502
> >
> >
> >
> > Ph. (831) 656-4111
> >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: John Halley Gotway
Time: Mon Jul 15 13:38:08 2019
Justin,
In a word, yes, adding "SYNOP" to the SURFACE entry of the
message_type_group_map tells Point-Stat to interpret observations of
that
type as existing at the surface. And when verifying against surface
obs,
Point-Stat skips over the logic of checking to make sure the vertical
level
matches.
I know that sending data from NRL can be difficult, so I posted an
example
on our ftp site. I'm running this Point-Stat command:
*met-8.1/bin/point_stat \*
*PYTHON_NUMPY \*
*sample_pb.nc <http://sample_pb.nc> PointStatConfig \*
*-outdir out -v 3 -obs_valid_beg 20000101 -obs_valid_end 20200101*
This just uses some sample obs that include wind speed from the MET
build.
That's why I set the matching time window to be 20 years (from 2000 to
2020)... just to make sure we get matches.
In the config file, I'm comparing 10-m wind from Python to wind speed
observations of type ADPUPA. And that produces 0 matched pairs:
*fcst = { field = [ { 'name="read_NRL_binary.py
wndspd_zht_0010.0_0000.0_glob360x181_2016122412_01200000_fcstfld"; }
];}obs = { field = [ { name = "WIND"; level = [ "Z10" ]; }
];}*
*message_type = [ "ADPUPA" ];*
*DEBUG 3: Number of matched pairs = 0DEBUG 3: Observations processed
=
87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected: level
mismatch = 8077DEBUG 3: Rejected: message type = 4522*
So then I tried what you're doing, adding ADPUPA to the list of
SURFACE
message types:
*message_type_group_map = [ { key = "SURFACE"; val =
"ADPSFC,SFCSHP,MSONET,ADPUPA"; },*
*...*
And when I rerun, I do now get matched pairs:
*DEBUG 3: Number of matched pairs = 5745DEBUG 3: Observations
processed
= 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
mismatch = 2332DEBUG 3: Rejected: message type = 4522*
So adding ADPUPA to that list of SURFACE obs produces the desired
result.
Beware though that this doesn't actually make sense scientifically for
this
data. The ADPUPA obs really are upper-air sounding observations, not
surface.
If your obs really are at the surface, adding "SYNOP" to the list
SURFACE
message types should enable them to match. I posted my testing files
here:
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/tsu_data_20190715/
Hope this example helps get you going.
Thanks,
John
On Fri, Jul 12, 2019 at 5:05 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Thanks John,
>
> My message type in my observation file is 'SYNOP' so I've changed
the
> message_type and message_group_type to SYNOP (SURFACE=SYNOP). Still
> getting 0
> matched pairs.
>
> Can you explain to me how point_stat uses the configuration file's
> definition
> of message_type=surface to compare with the forecast? You've
already
> explained to me that by providing point_Stat with a zht_10 UWIND
field,
> point_Stat automatically considers this surface data; hence, my
forecast
> is
> at the surface. Now, when I put message_type=SYNOP (and
SURFACE={SYNOP}
> in
> message_group_type), does point_stat now consider my obs to be at
the
> surface?
> At this point, are my obs and fcst at the same vertical level in
the MET
> domain?
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, July 12, 2019 3:30 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Justin,
>
> The message_type is an attribute of the observations. So it only
needs to
> appear in the "obs" dictionary. But having it in the "fcst"
dictionary as
> well should have no effect. The ADPSFC message type indicates to
MET that
> the observations occur at the surface... that's their special
meaning.
>
> Yes, looking at the counts I see that most are being discard because
they
> don't match the requested message type (12515) and others are off
your
> model domain (1565):
>
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: off the grid = 1565
>
> So you just need to take a look at how the point observations are
encoded
> in the point observation NetCDF file:
> sfc_2019042612.nc
>
> If you have access to R, you can dump those to ascii which is more
> readable, by running:
> Rscript /software/depot/met/met-
8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
> sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
>
> Do you actually have ADPSFC message types in there? And if so, do
they
> actually fall inside your model domain?
>
> MET's plot_point_obs tool can be helpful in answering these
questions, but
> since you're using Python embedding, that complicates things a bit.
>
> Let me know what additional questions you have.
>
> Thanks,
> John
>
>
> On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> > Hi John,
> >
> > Thank you for your descriptive response and apologies for the
delay. I
> > got
> > caught up in some other work.
> >
> > I am investigating the second method you proposed which was to use
> ADPSFC.
> > Couple questions here:
> >
> > 1. Does ADPSFC have any meaning other than to use it as a
reference to
> > link
> > obs and fcst to the same message group type (SURFACE)?
> >
> > 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed to
> > assign message_type ADPSFC to both obs and fcst dictionaries?
> >
> > I ended up testing message_type=ADPSFC for both obs and fcst to
test it
> > out:
> >
> > 73 fcst = {
> > 74
> > 75
> > 76 field = [
> > 77 {
> > 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> > uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> > 79 message_type = ["ADPSFC"];
> > 80 }
> > 81
> > 82 ];
> > 83
> > 84 }
> > 85
> > 86 obs = {
> > 87 field = [
> > 88 {
> > 89 file_type = NETCDF_NCCF;
> > 90 name = "ws";
> > 91 level = ["P975-P1000"];
> > 92 message_type = ["ADPSFC"];
> > 93 }
> > 94 ];
> > 95 }
> >
> > If I am understanding your message correctly, if I set the message
types
> > of
> > both fcst and obs to ADPSFC, point_stat will ignore the
> > height/level/elevation
> > columns of my observations and my forecast field and just compare
as is
> > with
> > necessary horizontal interpolation. Is this correct?
> >
> > Either way, running it this way gives me 0 matched pairs...
> >
> > point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> > DEBUG 1: Default Config File:
> >
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> > DEBUG 1: User Config File: config.rc
> > GSL_RNG_TYPE=mt19937
> > GSL_RNG_SEED=99166301
> > DEBUG 1: Forecast File: PYTHON_NUMPY
> > DEBUG 1: Observation File: sfc_2019042612.nc
> > Input File:
> > 'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> > Data Shape: (73, 75)
> > Data Type: dtype('float64')
> > Data Range: -5.4485907554626465 to 11.497947692871094
> > Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
> > '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere':
'N',
> > 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> > Test
> > Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx':
75, 'ny':
> > 73,
> > 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0},
'name':
> > 'uuwind',
> > 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Reading data for uuwind/zht_000010.
> > DEBUG 3: Use the forecast grid.
> > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny:
73
> > Lat_LL:
> > 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716
> Bx:
> > 283.3939 By: -23.3975
> > DEBUG 2: Processing masking regions.
> > DEBUG 3: Processing grid mask: FULL
> > DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology
> mean
> > levels, and 0 climatology standard deviation levels.
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Searching 14080 observations from 1800 messages.
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for
observation type
> > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 3: Number of matched pairs = 0
> > DEBUG 3: Observations processed = 14080
> > DEBUG 3: Rejected: SID exclusion = 0
> > DEBUG 3: Rejected: obs type = 12515
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 0
> > DEBUG 3: Rejected: off the grid = 1565
> > DEBUG 3: Rejected: level mismatch = 0
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 0
> > DEBUG 3: Rejected: masking region = 0
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: duplicates = 0
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V_cnt.txt
> >
> >
> > Justin
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, June 21, 2019 12:59 PM
> > To: Tsu, Mr. Justin
> > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> >
> > Hi Justin,
> >
> > I see you have a question about using Python embedding in Point-
Stat. So
> > you're passing a single forecast field of 10 m wind to Point-Stat
and
> want
> > to compare it to point observations. But your point observations
are in
> > pressure, not height.
> >
> > Here's some information which applies to this situation...
> >
> > First, Point-Stat does not do any conversion of pressure to height
for
> you,
> > or vice versa. However, typically point observations include both
a
> height
> > above ground and a pressure level. For example, the ascii2nc tool
in MET
> > can read a simple 11-column ascii point observation format:
> > The "met_point" ASCII format consists of 11 columns:
> > Message_Type Station_ID
Valid_Time(YYYYMMDD_HHMMSS)
> > Lat(Deg North) Lon(Deg East) Elevation(msl)
> > Var_Name(or GRIB_Code) Level Height(msl or agl)
> > QC_String Observation_Value
> > For a sounding, the pressure level is listed in the "Level" column
and
> the
> > height is listed in the "Height" column. Take a look at the point
> > observations you're using to see if you have both height and
pressure
> > listed.
> >
> > Second, typically, 2-m temperature and 10-m winds are considered
to be
> > forecasts at the "surface". Adopting the logic from NCEP's
verification
> > package, on which MET was originally based, the matching for
surface
> fields
> > is done by the message type, not the actual vertical level. For
example,
> > let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
> > and you're verifying it against the ADPSFC message type (land
surface
> > observations). Point-Stat doesn't actually check the height of
the
> > observation to make sure it's exactly 2. Instead, all ADPSFC
> observations
> > are automatically used since they are assumed to live at the
surface.
> Take
> > a look at the PointStatConfig file, the "message_type_group" map's
entry
> > for "SURFACE" defines the message types for which this logic
should be
> > applied:
> >
> > //
> > // Mapping of message type group name to comma-separated list of
values.
> > //
> > message_type_group_map = [
> > { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET";
},
> > { key = "ANYAIR"; val = "AIRCAR,AIRCFT";
},
> > { key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET";
},
> > { key = "ONLYSF"; val = "ADPSFC,SFCSHP";
},
> > { key = "LANDSF"; val = "ADPSFC,MSONET";
},
> > { key = "WATERSF"; val = "SFCSHP";
}
> > ];
> >
> > Third, there are many ways to configure Point-Stat to control what
range
> of
> > vertical levels are used in the verification, both in the forecast
and
> > observation data sources. For example, let's say you're verifying
500mb
> > temperature against upper-air observations. Here's 3 ways you
could
> > configure it:
> >
> > (1) Single forecast field versus single observation level:
> > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > obs = fcst;
> >
> > (2) Single forecast field versus range of observation levels:
> > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
> >
> > (3) Range of forecast fields versus range of observation levels:
> > fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> > obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
> >
> > In (1) and (2), we do not vertical interpolation of the forecast
data
> since
> > you've only requested a single level. In (3), we'll read data for
400,
> > 500, and 600 mb levels, but only use obs falling between 450 and
550.
> For
> > each obs, we'll vertically interpolate the forecast values from
the
> levels
> > above/below it to the actual pressure level of the obs.
> >
> > So lots of configuration options.
> >
> > If that answers your question, then great. If not, you could send
me
> some
> > sample data with a description of what you're trying to do, and I
can run
> > it here.
> >
> > Thanks,
> > John Halley Gotway
> >
> >
> > On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > > Queue: met_help
> > > Subject: Questions about point_stat
> > > Owner: Nobody
> > > Requestors: justin.tsu at nrlmry.navy.mil
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
> >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > I'm trying to use python embedding within point stat to verify a
model
> > > field
> > > of wind at 10 m using raobs whose positions are in pressure. Is
there
> a
> > > value in the config file that I need to set so that point_Stat
knows to
> > > interpolate to a common height between meter and pressure?
Because
> right
> > > now
> > > I'm getting 0 matched pairs when I run point_stat
> > >
> > >
> > >
> > > Justin
> > >
> > >
> > >
> > > Justin Tsu
> > >
> > > Marine Meteorology Division
> > >
> > > Data Assimilation/Mesoscale Modeling
> > >
> > > Building 704 Room 212
> > >
> > > Naval Research Laboratory, Code 7531
> > >
> > > 7 Grace Hopper Avenue
> > >
> > > Monterey, CA 93943-5502
> > >
> > >
> > >
> > > Ph. (831) 656-4111
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: Tsu, Mr. Justin
Time: Thu Jul 18 17:40:27 2019
Thanks for the example.
Am I understanding that the obs_valid_beg and obs_valid_end parameters
make all obs (in this example) in your netCDF file that fall between
2000 and 2020 are valid candidates for comparison against the wind
speed field?
I have been trying to get some matched pairs using my data set but to
no avail... even when I use SYNOP as surface message type. I think it
might just be my data that isn't matching.... after all I am comparing
U component of wind to wind speed obs so these values probably don’t
come close to each other. Can you recommend any debugging method I
can use to help focus in on what might be responsible for not getting
matched pairs (or to confirm that it is indeed just a mismatch in
forecast vs obs)?
Thanks,
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, July 15, 2019 12:38 PM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
Justin,
In a word, yes, adding "SYNOP" to the SURFACE entry of the
message_type_group_map tells Point-Stat to interpret observations of
that
type as existing at the surface. And when verifying against surface
obs,
Point-Stat skips over the logic of checking to make sure the vertical
level
matches.
I know that sending data from NRL can be difficult, so I posted an
example
on our ftp site. I'm running this Point-Stat command:
*met-8.1/bin/point_stat \*
*PYTHON_NUMPY \*
*sample_pb.nc <http://sample_pb.nc> PointStatConfig \*
*-outdir out -v 3 -obs_valid_beg 20000101 -obs_valid_end 20200101*
This just uses some sample obs that include wind speed from the MET
build.
That's why I set the matching time window to be 20 years (from 2000 to
2020)... just to make sure we get matches.
In the config file, I'm comparing 10-m wind from Python to wind speed
observations of type ADPUPA. And that produces 0 matched pairs:
*fcst = { field = [ { 'name="read_NRL_binary.py
wndspd_zht_0010.0_0000.0_glob360x181_2016122412_01200000_fcstfld"; }
];}obs = { field = [ { name = "WIND"; level = [ "Z10" ]; }
];}*
*message_type = [ "ADPUPA" ];*
*DEBUG 3: Number of matched pairs = 0DEBUG 3: Observations processed
=
87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected: level
mismatch = 8077DEBUG 3: Rejected: message type = 4522*
So then I tried what you're doing, adding ADPUPA to the list of
SURFACE
message types:
*message_type_group_map = [ { key = "SURFACE"; val =
"ADPSFC,SFCSHP,MSONET,ADPUPA"; },*
*...*
And when I rerun, I do now get matched pairs:
*DEBUG 3: Number of matched pairs = 5745DEBUG 3: Observations
processed
= 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
mismatch = 2332DEBUG 3: Rejected: message type = 4522*
So adding ADPUPA to that list of SURFACE obs produces the desired
result.
Beware though that this doesn't actually make sense scientifically for
this
data. The ADPUPA obs really are upper-air sounding observations, not
surface.
If your obs really are at the surface, adding "SYNOP" to the list
SURFACE
message types should enable them to match. I posted my testing files
here:
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/tsu_data_20190715/
Hope this example helps get you going.
Thanks,
John
On Fri, Jul 12, 2019 at 5:05 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Thanks John,
>
> My message type in my observation file is 'SYNOP' so I've changed
the
> message_type and message_group_type to SYNOP (SURFACE=SYNOP). Still
> getting 0
> matched pairs.
>
> Can you explain to me how point_stat uses the configuration file's
> definition
> of message_type=surface to compare with the forecast? You've
already
> explained to me that by providing point_Stat with a zht_10 UWIND
field,
> point_Stat automatically considers this surface data; hence, my
forecast
> is
> at the surface. Now, when I put message_type=SYNOP (and
SURFACE={SYNOP}
> in
> message_group_type), does point_stat now consider my obs to be at
the
> surface?
> At this point, are my obs and fcst at the same vertical level in
the MET
> domain?
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, July 12, 2019 3:30 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Justin,
>
> The message_type is an attribute of the observations. So it only
needs to
> appear in the "obs" dictionary. But having it in the "fcst"
dictionary as
> well should have no effect. The ADPSFC message type indicates to
MET that
> the observations occur at the surface... that's their special
meaning.
>
> Yes, looking at the counts I see that most are being discard because
they
> don't match the requested message type (12515) and others are off
your
> model domain (1565):
>
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: off the grid = 1565
>
> So you just need to take a look at how the point observations are
encoded
> in the point observation NetCDF file:
> sfc_2019042612.nc
>
> If you have access to R, you can dump those to ascii which is more
> readable, by running:
> Rscript /software/depot/met/met-
8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
> sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
>
> Do you actually have ADPSFC message types in there? And if so, do
they
> actually fall inside your model domain?
>
> MET's plot_point_obs tool can be helpful in answering these
questions, but
> since you're using Python embedding, that complicates things a bit.
>
> Let me know what additional questions you have.
>
> Thanks,
> John
>
>
> On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> > Hi John,
> >
> > Thank you for your descriptive response and apologies for the
delay. I
> > got
> > caught up in some other work.
> >
> > I am investigating the second method you proposed which was to use
> ADPSFC.
> > Couple questions here:
> >
> > 1. Does ADPSFC have any meaning other than to use it as a
reference to
> > link
> > obs and fcst to the same message group type (SURFACE)?
> >
> > 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed to
> > assign message_type ADPSFC to both obs and fcst dictionaries?
> >
> > I ended up testing message_type=ADPSFC for both obs and fcst to
test it
> > out:
> >
> > 73 fcst = {
> > 74
> > 75
> > 76 field = [
> > 77 {
> > 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> > uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> > 79 message_type = ["ADPSFC"];
> > 80 }
> > 81
> > 82 ];
> > 83
> > 84 }
> > 85
> > 86 obs = {
> > 87 field = [
> > 88 {
> > 89 file_type = NETCDF_NCCF;
> > 90 name = "ws";
> > 91 level = ["P975-P1000"];
> > 92 message_type = ["ADPSFC"];
> > 93 }
> > 94 ];
> > 95 }
> >
> > If I am understanding your message correctly, if I set the message
types
> > of
> > both fcst and obs to ADPSFC, point_stat will ignore the
> > height/level/elevation
> > columns of my observations and my forecast field and just compare
as is
> > with
> > necessary horizontal interpolation. Is this correct?
> >
> > Either way, running it this way gives me 0 matched pairs...
> >
> > point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> > DEBUG 1: Default Config File:
> >
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> > DEBUG 1: User Config File: config.rc
> > GSL_RNG_TYPE=mt19937
> > GSL_RNG_SEED=99166301
> > DEBUG 1: Forecast File: PYTHON_NUMPY
> > DEBUG 1: Observation File: sfc_2019042612.nc
> > Input File:
> > 'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> > Data Shape: (73, 75)
> > Data Type: dtype('float64')
> > Data Range: -5.4485907554626465 to 11.497947692871094
> > Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
> > '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere':
'N',
> > 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> > Test
> > Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx':
75, 'ny':
> > 73,
> > 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0},
'name':
> > 'uuwind',
> > 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Reading data for uuwind/zht_000010.
> > DEBUG 3: Use the forecast grid.
> > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny:
73
> > Lat_LL:
> > 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716
> Bx:
> > 283.3939 By: -23.3975
> > DEBUG 2: Processing masking regions.
> > DEBUG 3: Processing grid mask: FULL
> > DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology
> mean
> > levels, and 0 climatology standard deviation levels.
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Searching 14080 observations from 1800 messages.
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for
observation type
> > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 3: Number of matched pairs = 0
> > DEBUG 3: Observations processed = 14080
> > DEBUG 3: Rejected: SID exclusion = 0
> > DEBUG 3: Rejected: obs type = 12515
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 0
> > DEBUG 3: Rejected: off the grid = 1565
> > DEBUG 3: Rejected: level mismatch = 0
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 0
> > DEBUG 3: Rejected: masking region = 0
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: duplicates = 0
> > DEBUG 2:
> > DEBUG
> > 2:
> >
>
--------------------------------------------------------------------------------
> > DEBUG 2:
> > DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V_cnt.txt
> >
> >
> > Justin
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, June 21, 2019 12:59 PM
> > To: Tsu, Mr. Justin
> > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> >
> > Hi Justin,
> >
> > I see you have a question about using Python embedding in Point-
Stat. So
> > you're passing a single forecast field of 10 m wind to Point-Stat
and
> want
> > to compare it to point observations. But your point observations
are in
> > pressure, not height.
> >
> > Here's some information which applies to this situation...
> >
> > First, Point-Stat does not do any conversion of pressure to height
for
> you,
> > or vice versa. However, typically point observations include both
a
> height
> > above ground and a pressure level. For example, the ascii2nc tool
in MET
> > can read a simple 11-column ascii point observation format:
> > The "met_point" ASCII format consists of 11 columns:
> > Message_Type Station_ID
Valid_Time(YYYYMMDD_HHMMSS)
> > Lat(Deg North) Lon(Deg East) Elevation(msl)
> > Var_Name(or GRIB_Code) Level Height(msl or agl)
> > QC_String Observation_Value
> > For a sounding, the pressure level is listed in the "Level" column
and
> the
> > height is listed in the "Height" column. Take a look at the point
> > observations you're using to see if you have both height and
pressure
> > listed.
> >
> > Second, typically, 2-m temperature and 10-m winds are considered
to be
> > forecasts at the "surface". Adopting the logic from NCEP's
verification
> > package, on which MET was originally based, the matching for
surface
> fields
> > is done by the message type, not the actual vertical level. For
example,
> > let's say you're verifying 2-m temperature (name = "TMP"; level =
"Z2";)
> > and you're verifying it against the ADPSFC message type (land
surface
> > observations). Point-Stat doesn't actually check the height of
the
> > observation to make sure it's exactly 2. Instead, all ADPSFC
> observations
> > are automatically used since they are assumed to live at the
surface.
> Take
> > a look at the PointStatConfig file, the "message_type_group" map's
entry
> > for "SURFACE" defines the message types for which this logic
should be
> > applied:
> >
> > //
> > // Mapping of message type group name to comma-separated list of
values.
> > //
> > message_type_group_map = [
> > { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET";
},
> > { key = "ANYAIR"; val = "AIRCAR,AIRCFT";
},
> > { key = "ANYSFC"; val = "ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET";
},
> > { key = "ONLYSF"; val = "ADPSFC,SFCSHP";
},
> > { key = "LANDSF"; val = "ADPSFC,MSONET";
},
> > { key = "WATERSF"; val = "SFCSHP";
}
> > ];
> >
> > Third, there are many ways to configure Point-Stat to control what
range
> of
> > vertical levels are used in the verification, both in the forecast
and
> > observation data sources. For example, let's say you're verifying
500mb
> > temperature against upper-air observations. Here's 3 ways you
could
> > configure it:
> >
> > (1) Single forecast field versus single observation level:
> > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > obs = fcst;
> >
> > (2) Single forecast field versus range of observation levels:
> > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
> >
> > (3) Range of forecast fields versus range of observation levels:
> > fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> > obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
> >
> > In (1) and (2), we do not vertical interpolation of the forecast
data
> since
> > you've only requested a single level. In (3), we'll read data for
400,
> > 500, and 600 mb levels, but only use obs falling between 450 and
550.
> For
> > each obs, we'll vertically interpolate the forecast values from
the
> levels
> > above/below it to the actual pressure level of the obs.
> >
> > So lots of configuration options.
> >
> > If that answers your question, then great. If not, you could send
me
> some
> > sample data with a description of what you're trying to do, and I
can run
> > it here.
> >
> > Thanks,
> > John Halley Gotway
> >
> >
> > On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > > Queue: met_help
> > > Subject: Questions about point_stat
> > > Owner: Nobody
> > > Requestors: justin.tsu at nrlmry.navy.mil
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
> >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > I'm trying to use python embedding within point stat to verify a
model
> > > field
> > > of wind at 10 m using raobs whose positions are in pressure. Is
there
> a
> > > value in the config file that I need to set so that point_Stat
knows to
> > > interpolate to a common height between meter and pressure?
Because
> right
> > > now
> > > I'm getting 0 matched pairs when I run point_stat
> > >
> > >
> > >
> > > Justin
> > >
> > >
> > >
> > > Justin Tsu
> > >
> > > Marine Meteorology Division
> > >
> > > Data Assimilation/Mesoscale Modeling
> > >
> > > Building 704 Room 212
> > >
> > > Naval Research Laboratory, Code 7531
> > >
> > > 7 Grace Hopper Avenue
> > >
> > > Monterey, CA 93943-5502
> > >
> > >
> > >
> > > Ph. (831) 656-4111
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: John Halley Gotway
Time: Fri Jul 19 15:47:00 2019
Justin,
Yes, that's correct. The -obs_valid_beg and -obs_valid_end command
line
options can be used to define the time window over which observations
should be used. This time window is usually defined in the point-stat
config file using the "obs_window" config option defined around the
valid
time of the forecast data. The -obs_valid_beg and -obs_valid_end
command
line options manually override those settings.
Justin, is it the case that you're still getting counts like this at
verbosity level 3:
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: off the grid = 1565
The fact that you're trying to compare U-wind to Wind Speed really
shouldn't matter at all. The MET code doesn't really care... it's all
just
numbers to the code. So it really comes down to getting it configured
well
to make the type of comparisons you'd like to make. And the DEBUG(3)
counts of reason codes is the best way of indicating why obs aren't
being
used.
FYI, I'll be at NRL 7/29 - 8/2 for the METplus tutorial. So if we
haven't
solved it by then, we can certainly figure it out that week.
Thanks,
John
On Thu, Jul 18, 2019 at 5:41 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Thanks for the example.
>
> Am I understanding that the obs_valid_beg and obs_valid_end
parameters
> make all obs (in this example) in your netCDF file that fall between
2000
> and 2020 are valid candidates for comparison against the wind speed
field?
>
> I have been trying to get some matched pairs using my data set but
to no
> avail... even when I use SYNOP as surface message type. I think it
might
> just be my data that isn't matching.... after all I am comparing U
> component of wind to wind speed obs so these values probably don’t
come
> close to each other. Can you recommend any debugging method I can
use to
> help focus in on what might be responsible for not getting matched
pairs
> (or to confirm that it is indeed just a mismatch in forecast vs
obs)?
>
> Thanks,
> Justin
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, July 15, 2019 12:38 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Justin,
>
> In a word, yes, adding "SYNOP" to the SURFACE entry of the
> message_type_group_map tells Point-Stat to interpret observations of
that
> type as existing at the surface. And when verifying against surface
obs,
> Point-Stat skips over the logic of checking to make sure the
vertical level
> matches.
>
> I know that sending data from NRL can be difficult, so I posted an
example
> on our ftp site. I'm running this Point-Stat command:
>
> *met-8.1/bin/point_stat \*
> *PYTHON_NUMPY \*
> *sample_pb.nc <http://sample_pb.nc> PointStatConfig \*
> *-outdir out -v 3 -obs_valid_beg 20000101 -obs_valid_end 20200101*
>
> This just uses some sample obs that include wind speed from the MET
build.
> That's why I set the matching time window to be 20 years (from 2000
to
> 2020)... just to make sure we get matches.
>
> In the config file, I'm comparing 10-m wind from Python to wind
speed
> observations of type ADPUPA. And that produces 0 matched pairs:
>
>
>
>
>
>
>
>
>
>
> *fcst = { field = [ { 'name="read_NRL_binary.py
> wndspd_zht_0010.0_0000.0_glob360x181_2016122412_01200000_fcstfld"; }
> ];}obs = { field = [ { name = "WIND"; level = [ "Z10" ]; }
];}*
> *message_type = [ "ADPUPA" ];*
>
>
>
>
>
> *DEBUG 3: Number of matched pairs = 0DEBUG 3: Observations
processed =
> 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> mismatch = 8077DEBUG 3: Rejected: message type = 4522*
>
> So then I tried what you're doing, adding ADPUPA to the list of
SURFACE
> message types:
>
>
> *message_type_group_map = [ { key = "SURFACE"; val =
> "ADPSFC,SFCSHP,MSONET,ADPUPA"; },*
> *...*
>
> And when I rerun, I do now get matched pairs:
>
>
>
>
>
> *DEBUG 3: Number of matched pairs = 5745DEBUG 3: Observations
processed
> = 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> mismatch = 2332DEBUG 3: Rejected: message type = 4522*
>
> So adding ADPUPA to that list of SURFACE obs produces the desired
result.
> Beware though that this doesn't actually make sense scientifically
for this
> data. The ADPUPA obs really are upper-air sounding observations,
not
> surface.
>
> If your obs really are at the surface, adding "SYNOP" to the list
SURFACE
> message types should enable them to match. I posted my testing
files here:
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/tsu_data_20190715/
>
> Hope this example helps get you going.
>
> Thanks,
> John
>
>
> On Fri, Jul 12, 2019 at 5:05 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> > Thanks John,
> >
> > My message type in my observation file is 'SYNOP' so I've changed
the
> > message_type and message_group_type to SYNOP (SURFACE=SYNOP).
Still
> > getting 0
> > matched pairs.
> >
> > Can you explain to me how point_stat uses the configuration file's
> > definition
> > of message_type=surface to compare with the forecast? You've
already
> > explained to me that by providing point_Stat with a zht_10 UWIND
field,
> > point_Stat automatically considers this surface data; hence, my
forecast
> > is
> > at the surface. Now, when I put message_type=SYNOP (and
SURFACE={SYNOP}
> > in
> > message_group_type), does point_stat now consider my obs to be at
the
> > surface?
> > At this point, are my obs and fcst at the same vertical level in
the MET
> > domain?
> >
> > Justin
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, July 12, 2019 3:30 PM
> > To: Tsu, Mr. Justin
> > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> >
> > Justin,
> >
> > The message_type is an attribute of the observations. So it only
needs
> to
> > appear in the "obs" dictionary. But having it in the "fcst"
dictionary
> as
> > well should have no effect. The ADPSFC message type indicates to
MET
> that
> > the observations occur at the surface... that's their special
meaning.
> >
> > Yes, looking at the counts I see that most are being discard
because they
> > don't match the requested message type (12515) and others are off
your
> > model domain (1565):
> >
> > DEBUG 3: Observations processed = 14080
> > DEBUG 3: Rejected: obs type = 12515
> > DEBUG 3: Rejected: off the grid = 1565
> >
> > So you just need to take a look at how the point observations are
encoded
> > in the point observation NetCDF file:
> > sfc_2019042612.nc
> >
> > If you have access to R, you can dump those to ascii which is more
> > readable, by running:
> > Rscript
> /software/depot/met/met-8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
> > sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
> >
> > Do you actually have ADPSFC message types in there? And if so, do
they
> > actually fall inside your model domain?
> >
> > MET's plot_point_obs tool can be helpful in answering these
questions,
> but
> > since you're using Python embedding, that complicates things a
bit.
> >
> > Let me know what additional questions you have.
> >
> > Thanks,
> > John
> >
> >
> > On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> > >
> > > Hi John,
> > >
> > > Thank you for your descriptive response and apologies for the
delay. I
> > > got
> > > caught up in some other work.
> > >
> > > I am investigating the second method you proposed which was to
use
> > ADPSFC.
> > > Couple questions here:
> > >
> > > 1. Does ADPSFC have any meaning other than to use it as a
reference to
> > > link
> > > obs and fcst to the same message group type (SURFACE)?
> > >
> > > 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed
> to
> > > assign message_type ADPSFC to both obs and fcst dictionaries?
> > >
> > > I ended up testing message_type=ADPSFC for both obs and fcst to
test it
> > > out:
> > >
> > > 73 fcst = {
> > > 74
> > > 75
> > > 76 field = [
> > > 77 {
> > > 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> > >
uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> > > 79 message_type = ["ADPSFC"];
> > > 80 }
> > > 81
> > > 82 ];
> > > 83
> > > 84 }
> > > 85
> > > 86 obs = {
> > > 87 field = [
> > > 88 {
> > > 89 file_type = NETCDF_NCCF;
> > > 90 name = "ws";
> > > 91 level = ["P975-P1000"];
> > > 92 message_type = ["ADPSFC"];
> > > 93 }
> > > 94 ];
> > > 95 }
> > >
> > > If I am understanding your message correctly, if I set the
message
> types
> > > of
> > > both fcst and obs to ADPSFC, point_stat will ignore the
> > > height/level/elevation
> > > columns of my observations and my forecast field and just
compare as is
> > > with
> > > necessary horizontal interpolation. Is this correct?
> > >
> > > Either way, running it this way gives me 0 matched pairs...
> > >
> > > point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> > > DEBUG 1: Default Config File:
> > >
> >
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> > > DEBUG 1: User Config File: config.rc
> > > GSL_RNG_TYPE=mt19937
> > > GSL_RNG_SEED=99166301
> > > DEBUG 1: Forecast File: PYTHON_NUMPY
> > > DEBUG 1: Observation File: sfc_2019042612.nc
> > > Input File:
> > >
'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> > > Data Shape: (73, 75)
> > > Data Type: dtype('float64')
> > > Data Range: -5.4485907554626465 to 11.497947692871094
> > > Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
> 'valid':
> > > '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere':
'N',
> > > 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> > > Test
> > > Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx':
75,
> 'ny':
> > > 73,
> > > 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0},
'name':
> > > 'uuwind',
> > > 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Reading data for uuwind/zht_000010.
> > > DEBUG 3: Use the forecast grid.
> > > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75
Ny: 73
> > > Lat_LL:
> > > 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716
> > Bx:
> > > 283.3939 By: -23.3975
> > > DEBUG 2: Processing masking regions.
> > > DEBUG 3: Processing grid mask: FULL
> > > DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology
> > mean
> > > levels, and 0 climatology standard deviation levels.
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Searching 14080 observations from 1800 messages.
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for
observation
> type
> > > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> > > pairs.
> > > DEBUG 3: Number of matched pairs = 0
> > > DEBUG 3: Observations processed = 14080
> > > DEBUG 3: Rejected: SID exclusion = 0
> > > DEBUG 3: Rejected: obs type = 12515
> > > DEBUG 3: Rejected: valid time = 0
> > > DEBUG 3: Rejected: bad obs value = 0
> > > DEBUG 3: Rejected: off the grid = 1565
> > > DEBUG 3: Rejected: level mismatch = 0
> > > DEBUG 3: Rejected: quality marker = 0
> > > DEBUG 3: Rejected: message type = 0
> > > DEBUG 3: Rejected: masking region = 0
> > > DEBUG 3: Rejected: bad fcst value = 0
> > > DEBUG 3: Rejected: duplicates = 0
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> > > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V_cnt.txt
> > >
> > >
> > > Justin
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Friday, June 21, 2019 12:59 PM
> > > To: Tsu, Mr. Justin
> > > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> > >
> > > Hi Justin,
> > >
> > > I see you have a question about using Python embedding in Point-
Stat.
> So
> > > you're passing a single forecast field of 10 m wind to Point-
Stat and
> > want
> > > to compare it to point observations. But your point
observations are
> in
> > > pressure, not height.
> > >
> > > Here's some information which applies to this situation...
> > >
> > > First, Point-Stat does not do any conversion of pressure to
height for
> > you,
> > > or vice versa. However, typically point observations include
both a
> > height
> > > above ground and a pressure level. For example, the ascii2nc
tool in
> MET
> > > can read a simple 11-column ascii point observation format:
> > > The "met_point" ASCII format consists of 11 columns:
> > > Message_Type Station_ID
Valid_Time(YYYYMMDD_HHMMSS)
> > > Lat(Deg North) Lon(Deg East) Elevation(msl)
> > > Var_Name(or GRIB_Code) Level Height(msl or agl)
> > > QC_String Observation_Value
> > > For a sounding, the pressure level is listed in the "Level"
column and
> > the
> > > height is listed in the "Height" column. Take a look at the
point
> > > observations you're using to see if you have both height and
pressure
> > > listed.
> > >
> > > Second, typically, 2-m temperature and 10-m winds are considered
to be
> > > forecasts at the "surface". Adopting the logic from NCEP's
> verification
> > > package, on which MET was originally based, the matching for
surface
> > fields
> > > is done by the message type, not the actual vertical level. For
> example,
> > > let's say you're verifying 2-m temperature (name = "TMP"; level
=
> "Z2";)
> > > and you're verifying it against the ADPSFC message type (land
surface
> > > observations). Point-Stat doesn't actually check the height of
the
> > > observation to make sure it's exactly 2. Instead, all ADPSFC
> > observations
> > > are automatically used since they are assumed to live at the
surface.
> > Take
> > > a look at the PointStatConfig file, the "message_type_group"
map's
> entry
> > > for "SURFACE" defines the message types for which this logic
should be
> > > applied:
> > >
> > > //
> > > // Mapping of message type group name to comma-separated list of
> values.
> > > //
> > > message_type_group_map = [
> > > { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET";
},
> > > { key = "ANYAIR"; val = "AIRCAR,AIRCFT";
},
> > > { key = "ANYSFC"; val =
"ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
> > > { key = "ONLYSF"; val = "ADPSFC,SFCSHP";
},
> > > { key = "LANDSF"; val = "ADPSFC,MSONET";
},
> > > { key = "WATERSF"; val = "SFCSHP";
}
> > > ];
> > >
> > > Third, there are many ways to configure Point-Stat to control
what
> range
> > of
> > > vertical levels are used in the verification, both in the
forecast and
> > > observation data sources. For example, let's say you're
verifying
> 500mb
> > > temperature against upper-air observations. Here's 3 ways you
could
> > > configure it:
> > >
> > > (1) Single forecast field versus single observation level:
> > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > obs = fcst;
> > >
> > > (2) Single forecast field versus range of observation levels:
> > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
> > >
> > > (3) Range of forecast fields versus range of observation levels:
> > > fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> > > obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
> > >
> > > In (1) and (2), we do not vertical interpolation of the forecast
data
> > since
> > > you've only requested a single level. In (3), we'll read data
for 400,
> > > 500, and 600 mb levels, but only use obs falling between 450 and
550.
> > For
> > > each obs, we'll vertically interpolate the forecast values from
the
> > levels
> > > above/below it to the actual pressure level of the obs.
> > >
> > > So lots of configuration options.
> > >
> > > If that answers your question, then great. If not, you could
send me
> > some
> > > sample data with a description of what you're trying to do, and
I can
> run
> > > it here.
> > >
> > > Thanks,
> > > John Halley Gotway
> > >
> > >
> > > On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT <
> > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > > > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > > > Queue: met_help
> > > > Subject: Questions about point_stat
> > > > Owner: Nobody
> > > > Requestors: justin.tsu at nrlmry.navy.mil
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
> > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > >
> > > >
> > > > I'm trying to use python embedding within point stat to verify
a
> model
> > > > field
> > > > of wind at 10 m using raobs whose positions are in pressure.
Is
> there
> > a
> > > > value in the config file that I need to set so that point_Stat
knows
> to
> > > > interpolate to a common height between meter and pressure?
Because
> > right
> > > > now
> > > > I'm getting 0 matched pairs when I run point_stat
> > > >
> > > >
> > > >
> > > > Justin
> > > >
> > > >
> > > >
> > > > Justin Tsu
> > > >
> > > > Marine Meteorology Division
> > > >
> > > > Data Assimilation/Mesoscale Modeling
> > > >
> > > > Building 704 Room 212
> > > >
> > > > Naval Research Laboratory, Code 7531
> > > >
> > > > 7 Grace Hopper Avenue
> > > >
> > > > Monterey, CA 93943-5502
> > > >
> > > >
> > > >
> > > > Ph. (831) 656-4111
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: Tsu, Mr. Justin
Time: Fri Jul 19 15:59:00 2019
I am getting those lines exactly when I run at -v 3.
And that's sort of what I thought... I might not get as many matched
pairs but I should definitely get at least one, particularly for east-
west winds.
Here is what I get:
[tsu at maury2 01_POINT_STAT_WORK]$ point_stat PYTHON_NUMPY
sfc_2019042612.nc config.rc -v 3 -obs_valid_beg 20000101
-obs_valid_end 20200101
DEBUG 1: Default Config File: /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
DEBUG 1: User Config File: config.rc
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=18446744072988275037
DEBUG 1: Forecast File: PYTHON_NUMPY
DEBUG 1: Observation File: sfc_2019042612.nc
Input File:
'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
Data Shape: (73, 75)
Data Type: dtype('float64')
Data Range: -5.4485907554626465 to 11.497947692871094
Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid': '20190426_120000', 'grid': {'scale_lat_2': 30.0,
'hemisphere': 'N', 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin':
38.0, 'name': 'COAMPS Test Grid', 'x_pin': 38.0, 'lon_orient': 238.0,
'y_pin': 37.0, 'nx': 75, 'ny': 73, 'r_km': 6361.2, 'type': 'Lambert
Conformal', 'd_km': 27.0}, 'name': 'uuwind', 'lead': '0', 'level':
'zht_000010', 'units': 'UNKNOWN', 'accum': '00'}
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for uuwind/zht_000010.
DEBUG 3: Use the forecast grid.
DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny: 73
Lat_LL: 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437
Cone: 0.716 Bx: 283.3939 By: -23.3975
DEBUG 2: Processing masking regions.
DEBUG 3: Processing grid mask: FULL
DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0 climatology
mean levels, and 0 climatology standard deviation levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 14080 observations from 1800 messages.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for observation
type SYNOP, over region FULL, for interpolation method NEAREST(1),
using 0 pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 1565
DEBUG 3: Rejected: level mismatch = 0
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 0
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V_cnt.txt
I will see you during your visit. I believe I spoke to Liz to reserve
some of your time
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, July 19, 2019 2:47 PM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
Justin,
Yes, that's correct. The -obs_valid_beg and -obs_valid_end command
line
options can be used to define the time window over which observations
should be used. This time window is usually defined in the point-stat
config file using the "obs_window" config option defined around the
valid
time of the forecast data. The -obs_valid_beg and -obs_valid_end
command
line options manually override those settings.
Justin, is it the case that you're still getting counts like this at
verbosity level 3:
DEBUG 3: Observations processed = 14080
DEBUG 3: Rejected: obs type = 12515
DEBUG 3: Rejected: off the grid = 1565
The fact that you're trying to compare U-wind to Wind Speed really
shouldn't matter at all. The MET code doesn't really care... it's all
just
numbers to the code. So it really comes down to getting it configured
well
to make the type of comparisons you'd like to make. And the DEBUG(3)
counts of reason codes is the best way of indicating why obs aren't
being
used.
FYI, I'll be at NRL 7/29 - 8/2 for the METplus tutorial. So if we
haven't
solved it by then, we can certainly figure it out that week.
Thanks,
John
On Thu, Jul 18, 2019 at 5:41 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> Thanks for the example.
>
> Am I understanding that the obs_valid_beg and obs_valid_end
parameters
> make all obs (in this example) in your netCDF file that fall between
2000
> and 2020 are valid candidates for comparison against the wind speed
field?
>
> I have been trying to get some matched pairs using my data set but
to no
> avail... even when I use SYNOP as surface message type. I think it
might
> just be my data that isn't matching.... after all I am comparing U
> component of wind to wind speed obs so these values probably don’t
come
> close to each other. Can you recommend any debugging method I can
use to
> help focus in on what might be responsible for not getting matched
pairs
> (or to confirm that it is indeed just a mismatch in forecast vs
obs)?
>
> Thanks,
> Justin
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, July 15, 2019 12:38 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Justin,
>
> In a word, yes, adding "SYNOP" to the SURFACE entry of the
> message_type_group_map tells Point-Stat to interpret observations of
that
> type as existing at the surface. And when verifying against surface
obs,
> Point-Stat skips over the logic of checking to make sure the
vertical level
> matches.
>
> I know that sending data from NRL can be difficult, so I posted an
example
> on our ftp site. I'm running this Point-Stat command:
>
> *met-8.1/bin/point_stat \*
> *PYTHON_NUMPY \*
> *sample_pb.nc <http://sample_pb.nc> PointStatConfig \*
> *-outdir out -v 3 -obs_valid_beg 20000101 -obs_valid_end 20200101*
>
> This just uses some sample obs that include wind speed from the MET
build.
> That's why I set the matching time window to be 20 years (from 2000
to
> 2020)... just to make sure we get matches.
>
> In the config file, I'm comparing 10-m wind from Python to wind
speed
> observations of type ADPUPA. And that produces 0 matched pairs:
>
>
>
>
>
>
>
>
>
>
> *fcst = { field = [ { 'name="read_NRL_binary.py
> wndspd_zht_0010.0_0000.0_glob360x181_2016122412_01200000_fcstfld"; }
> ];}obs = { field = [ { name = "WIND"; level = [ "Z10" ]; }
];}*
> *message_type = [ "ADPUPA" ];*
>
>
>
>
>
> *DEBUG 3: Number of matched pairs = 0DEBUG 3: Observations
processed =
> 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> mismatch = 8077DEBUG 3: Rejected: message type = 4522*
>
> So then I tried what you're doing, adding ADPUPA to the list of
SURFACE
> message types:
>
>
> *message_type_group_map = [ { key = "SURFACE"; val =
> "ADPSFC,SFCSHP,MSONET,ADPUPA"; },*
> *...*
>
> And when I rerun, I do now get matched pairs:
>
>
>
>
>
> *DEBUG 3: Number of matched pairs = 5745DEBUG 3: Observations
processed
> = 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> mismatch = 2332DEBUG 3: Rejected: message type = 4522*
>
> So adding ADPUPA to that list of SURFACE obs produces the desired
result.
> Beware though that this doesn't actually make sense scientifically
for this
> data. The ADPUPA obs really are upper-air sounding observations,
not
> surface.
>
> If your obs really are at the surface, adding "SYNOP" to the list
SURFACE
> message types should enable them to match. I posted my testing
files here:
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/tsu_data_20190715/
>
> Hope this example helps get you going.
>
> Thanks,
> John
>
>
> On Fri, Jul 12, 2019 at 5:05 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> > Thanks John,
> >
> > My message type in my observation file is 'SYNOP' so I've changed
the
> > message_type and message_group_type to SYNOP (SURFACE=SYNOP).
Still
> > getting 0
> > matched pairs.
> >
> > Can you explain to me how point_stat uses the configuration file's
> > definition
> > of message_type=surface to compare with the forecast? You've
already
> > explained to me that by providing point_Stat with a zht_10 UWIND
field,
> > point_Stat automatically considers this surface data; hence, my
forecast
> > is
> > at the surface. Now, when I put message_type=SYNOP (and
SURFACE={SYNOP}
> > in
> > message_group_type), does point_stat now consider my obs to be at
the
> > surface?
> > At this point, are my obs and fcst at the same vertical level in
the MET
> > domain?
> >
> > Justin
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Friday, July 12, 2019 3:30 PM
> > To: Tsu, Mr. Justin
> > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> >
> > Justin,
> >
> > The message_type is an attribute of the observations. So it only
needs
> to
> > appear in the "obs" dictionary. But having it in the "fcst"
dictionary
> as
> > well should have no effect. The ADPSFC message type indicates to
MET
> that
> > the observations occur at the surface... that's their special
meaning.
> >
> > Yes, looking at the counts I see that most are being discard
because they
> > don't match the requested message type (12515) and others are off
your
> > model domain (1565):
> >
> > DEBUG 3: Observations processed = 14080
> > DEBUG 3: Rejected: obs type = 12515
> > DEBUG 3: Rejected: off the grid = 1565
> >
> > So you just need to take a look at how the point observations are
encoded
> > in the point observation NetCDF file:
> > sfc_2019042612.nc
> >
> > If you have access to R, you can dump those to ascii which is more
> > readable, by running:
> > Rscript
> /software/depot/met/met-8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
> > sfc_2019042612.nc > sfc_2019042612.txt <http://sfc_2019042612.nc>
> >
> > Do you actually have ADPSFC message types in there? And if so, do
they
> > actually fall inside your model domain?
> >
> > MET's plot_point_obs tool can be helpful in answering these
questions,
> but
> > since you're using Python embedding, that complicates things a
bit.
> >
> > Let me know what additional questions you have.
> >
> > Thanks,
> > John
> >
> >
> > On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> > >
> > > Hi John,
> > >
> > > Thank you for your descriptive response and apologies for the
delay. I
> > > got
> > > caught up in some other work.
> > >
> > > I am investigating the second method you proposed which was to
use
> > ADPSFC.
> > > Couple questions here:
> > >
> > > 1. Does ADPSFC have any meaning other than to use it as a
reference to
> > > link
> > > obs and fcst to the same message group type (SURFACE)?
> > >
> > > 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed
> to
> > > assign message_type ADPSFC to both obs and fcst dictionaries?
> > >
> > > I ended up testing message_type=ADPSFC for both obs and fcst to
test it
> > > out:
> > >
> > > 73 fcst = {
> > > 74
> > > 75
> > > 76 field = [
> > > 77 {
> > > 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> > >
uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> > > 79 message_type = ["ADPSFC"];
> > > 80 }
> > > 81
> > > 82 ];
> > > 83
> > > 84 }
> > > 85
> > > 86 obs = {
> > > 87 field = [
> > > 88 {
> > > 89 file_type = NETCDF_NCCF;
> > > 90 name = "ws";
> > > 91 level = ["P975-P1000"];
> > > 92 message_type = ["ADPSFC"];
> > > 93 }
> > > 94 ];
> > > 95 }
> > >
> > > If I am understanding your message correctly, if I set the
message
> types
> > > of
> > > both fcst and obs to ADPSFC, point_stat will ignore the
> > > height/level/elevation
> > > columns of my observations and my forecast field and just
compare as is
> > > with
> > > necessary horizontal interpolation. Is this correct?
> > >
> > > Either way, running it this way gives me 0 matched pairs...
> > >
> > > point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> > > DEBUG 1: Default Config File:
> > >
> >
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> > > DEBUG 1: User Config File: config.rc
> > > GSL_RNG_TYPE=mt19937
> > > GSL_RNG_SEED=99166301
> > > DEBUG 1: Forecast File: PYTHON_NUMPY
> > > DEBUG 1: Observation File: sfc_2019042612.nc
> > > Input File:
> > >
'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> > > Data Shape: (73, 75)
> > > Data Type: dtype('float64')
> > > Data Range: -5.4485907554626465 to 11.497947692871094
> > > Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
> 'valid':
> > > '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere':
'N',
> > > 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> > > Test
> > > Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx':
75,
> 'ny':
> > > 73,
> > > 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0},
'name':
> > > 'uuwind',
> > > 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN', 'accum':
'00'}
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Reading data for uuwind/zht_000010.
> > > DEBUG 3: Use the forecast grid.
> > > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75
Ny: 73
> > > Lat_LL:
> > > 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437 Cone:
0.716
> > Bx:
> > > 283.3939 By: -23.3975
> > > DEBUG 2: Processing masking regions.
> > > DEBUG 3: Processing grid mask: FULL
> > > DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology
> > mean
> > > levels, and 0 climatology standard deviation levels.
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Searching 14080 observations from 1800 messages.
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for
observation
> type
> > > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> > > pairs.
> > > DEBUG 3: Number of matched pairs = 0
> > > DEBUG 3: Observations processed = 14080
> > > DEBUG 3: Rejected: SID exclusion = 0
> > > DEBUG 3: Rejected: obs type = 12515
> > > DEBUG 3: Rejected: valid time = 0
> > > DEBUG 3: Rejected: bad obs value = 0
> > > DEBUG 3: Rejected: off the grid = 1565
> > > DEBUG 3: Rejected: level mismatch = 0
> > > DEBUG 3: Rejected: quality marker = 0
> > > DEBUG 3: Rejected: message type = 0
> > > DEBUG 3: Rejected: masking region = 0
> > > DEBUG 3: Rejected: bad fcst value = 0
> > > DEBUG 3: Rejected: duplicates = 0
> > > DEBUG 2:
> > > DEBUG
> > > 2:
> > >
> >
>
--------------------------------------------------------------------------------
> > > DEBUG 2:
> > > DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> > > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V_cnt.txt
> > >
> > >
> > > Justin
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Friday, June 21, 2019 12:59 PM
> > > To: Tsu, Mr. Justin
> > > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> > >
> > > Hi Justin,
> > >
> > > I see you have a question about using Python embedding in Point-
Stat.
> So
> > > you're passing a single forecast field of 10 m wind to Point-
Stat and
> > want
> > > to compare it to point observations. But your point
observations are
> in
> > > pressure, not height.
> > >
> > > Here's some information which applies to this situation...
> > >
> > > First, Point-Stat does not do any conversion of pressure to
height for
> > you,
> > > or vice versa. However, typically point observations include
both a
> > height
> > > above ground and a pressure level. For example, the ascii2nc
tool in
> MET
> > > can read a simple 11-column ascii point observation format:
> > > The "met_point" ASCII format consists of 11 columns:
> > > Message_Type Station_ID
Valid_Time(YYYYMMDD_HHMMSS)
> > > Lat(Deg North) Lon(Deg East) Elevation(msl)
> > > Var_Name(or GRIB_Code) Level Height(msl or agl)
> > > QC_String Observation_Value
> > > For a sounding, the pressure level is listed in the "Level"
column and
> > the
> > > height is listed in the "Height" column. Take a look at the
point
> > > observations you're using to see if you have both height and
pressure
> > > listed.
> > >
> > > Second, typically, 2-m temperature and 10-m winds are considered
to be
> > > forecasts at the "surface". Adopting the logic from NCEP's
> verification
> > > package, on which MET was originally based, the matching for
surface
> > fields
> > > is done by the message type, not the actual vertical level. For
> example,
> > > let's say you're verifying 2-m temperature (name = "TMP"; level
=
> "Z2";)
> > > and you're verifying it against the ADPSFC message type (land
surface
> > > observations). Point-Stat doesn't actually check the height of
the
> > > observation to make sure it's exactly 2. Instead, all ADPSFC
> > observations
> > > are automatically used since they are assumed to live at the
surface.
> > Take
> > > a look at the PointStatConfig file, the "message_type_group"
map's
> entry
> > > for "SURFACE" defines the message types for which this logic
should be
> > > applied:
> > >
> > > //
> > > // Mapping of message type group name to comma-separated list of
> values.
> > > //
> > > message_type_group_map = [
> > > { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET";
},
> > > { key = "ANYAIR"; val = "AIRCAR,AIRCFT";
},
> > > { key = "ANYSFC"; val =
"ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
> > > { key = "ONLYSF"; val = "ADPSFC,SFCSHP";
},
> > > { key = "LANDSF"; val = "ADPSFC,MSONET";
},
> > > { key = "WATERSF"; val = "SFCSHP";
}
> > > ];
> > >
> > > Third, there are many ways to configure Point-Stat to control
what
> range
> > of
> > > vertical levels are used in the verification, both in the
forecast and
> > > observation data sources. For example, let's say you're
verifying
> 500mb
> > > temperature against upper-air observations. Here's 3 ways you
could
> > > configure it:
> > >
> > > (1) Single forecast field versus single observation level:
> > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > obs = fcst;
> > >
> > > (2) Single forecast field versus range of observation levels:
> > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
> > >
> > > (3) Range of forecast fields versus range of observation levels:
> > > fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> > > obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
> > >
> > > In (1) and (2), we do not vertical interpolation of the forecast
data
> > since
> > > you've only requested a single level. In (3), we'll read data
for 400,
> > > 500, and 600 mb levels, but only use obs falling between 450 and
550.
> > For
> > > each obs, we'll vertically interpolate the forecast values from
the
> > levels
> > > above/below it to the actual pressure level of the obs.
> > >
> > > So lots of configuration options.
> > >
> > > If that answers your question, then great. If not, you could
send me
> > some
> > > sample data with a description of what you're trying to do, and
I can
> run
> > > it here.
> > >
> > > Thanks,
> > > John Halley Gotway
> > >
> > >
> > > On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT <
> > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > > > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > > > Queue: met_help
> > > > Subject: Questions about point_stat
> > > > Owner: Nobody
> > > > Requestors: justin.tsu at nrlmry.navy.mil
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
> > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > >
> > > >
> > > > I'm trying to use python embedding within point stat to verify
a
> model
> > > > field
> > > > of wind at 10 m using raobs whose positions are in pressure.
Is
> there
> > a
> > > > value in the config file that I need to set so that point_Stat
knows
> to
> > > > interpolate to a common height between meter and pressure?
Because
> > right
> > > > now
> > > > I'm getting 0 matched pairs when I run point_stat
> > > >
> > > >
> > > >
> > > > Justin
> > > >
> > > >
> > > >
> > > > Justin Tsu
> > > >
> > > > Marine Meteorology Division
> > > >
> > > > Data Assimilation/Mesoscale Modeling
> > > >
> > > > Building 704 Room 212
> > > >
> > > > Naval Research Laboratory, Code 7531
> > > >
> > > > 7 Grace Hopper Avenue
> > > >
> > > > Monterey, CA 93943-5502
> > > >
> > > >
> > > >
> > > > Ph. (831) 656-4111
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Questions about point_stat
From: John Halley Gotway
Time: Fri Jul 19 16:16:10 2019
Justin,
Here's what these debug lines actually mean...
DEBUG 3: Observations processed = 14080 (Point-Stat read this number
of
point observations from the input file.)
DEBUG 3: Rejected: obs type = 12515 (This many of those
observations
don't match the "name" specified in the "obs" dictionary.)
DEBUG 3: Rejected: off the grid = 1565 (This many of those
observations
do match the "name" but don't actually fall in your model domain.)
If I had the data, here's how I'd debug.
Question 1: Are these counts roughly correct?
You are looking for observations named "ws". Do you actually have
about
1,565 observations of "ws" in your dataset? I'd find out by running
this
Rscript:
* Rscript met-8.1/share/met/Rscripts/pntnc2ascii.R sfc_2019042612.nc
<http://sfc_2019042612.nc> > sfc_2019042612.txt*
* grep " ws " **sfc_2019042612.txt | wc -l*
This Rscript dumps the NetCDF point obs to ascii, making them easier
to
grep.
Question 2: Where do your "ws" point obs actually exist on the earth?
Run plot_point_obs to draw a dot for each "ws" point observation
location:
* met-8.1/bin/plot_point_obs sfc_2019042612.nc
<http://sfc_2019042612.nc>
sfc_2019042612.ps <http://sfc_2019042612.ps> -obs_var ws*
By default, it'll plot the dots on a global grid, which is fine.
I wonder though if you'll see no dots? Perhaps there's some problem
with
the lat/lon values of your obs?
* cat *
*sfc_2019042612.txt | awk '{print $4, $5}'*
The lat/lon values are listed in columns 4 and 5, respectively.
Confirm
that the lat's are -90 to 90 and lons are -180 to 180 (or 0 to 360).
Thanks,
John
On Fri, Jul 19, 2019 at 3:59 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
>
> I am getting those lines exactly when I run at -v 3.
>
> And that's sort of what I thought... I might not get as many matched
pairs
> but I should definitely get at least one, particularly for east-west
> winds.
>
>
> Here is what I get:
> [tsu at maury2 01_POINT_STAT_WORK]$ point_stat PYTHON_NUMPY
> sfc_2019042612.nc config.rc -v 3 -obs_valid_beg 20000101
-obs_valid_end
> 20200101
> DEBUG 1: Default Config File:
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config.rc
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=18446744072988275037
> DEBUG 1: Forecast File: PYTHON_NUMPY
> DEBUG 1: Observation File: sfc_2019042612.nc
> Input File:
> 'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> Data Shape: (73, 75)
> Data Type: dtype('float64')
> Data Range: -5.4485907554626465 to 11.497947692871094
> Attributes: {'long_name': 'UNKNOWN', 'init': '20190426_120000',
'valid':
> '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere': 'N',
> 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0, 'name':
'COAMPS
> Test Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0, 'nx':
75,
> 'ny': 73, 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km':
27.0},
> 'name': 'uuwind', 'lead': '0', 'level': 'zht_000010', 'units':
'UNKNOWN',
> 'accum': '00'}
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for uuwind/zht_000010.
> DEBUG 3: Use the forecast grid.
> DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75 Ny:
73
> Lat_LL: 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437
Cone:
> 0.716 Bx: 283.3939 By: -23.3975
> DEBUG 2: Processing masking regions.
> DEBUG 3: Processing grid mask: FULL
> DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology mean
> levels, and 0 climatology standard deviation levels.
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Searching 14080 observations from 1800 messages.
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for observation
type
> SYNOP, over region FULL, for interpolation method NEAREST(1), using
0 pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 1565
> DEBUG 3: Rejected: level mismatch = 0
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V.stat
> DEBUG 1: Output file: ./point_stat_000000L_20190426_120000V_cnt.txt
>
>
>
> I will see you during your visit. I believe I spoke to Liz to
reserve some
> of your time
>
> Justin
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, July 19, 2019 2:47 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
>
> Justin,
>
> Yes, that's correct. The -obs_valid_beg and -obs_valid_end command
line
> options can be used to define the time window over which
observations
> should be used. This time window is usually defined in the point-
stat
> config file using the "obs_window" config option defined around the
valid
> time of the forecast data. The -obs_valid_beg and -obs_valid_end
command
> line options manually override those settings.
>
> Justin, is it the case that you're still getting counts like this at
> verbosity level 3:
> DEBUG 3: Observations processed = 14080
> DEBUG 3: Rejected: obs type = 12515
> DEBUG 3: Rejected: off the grid = 1565
>
> The fact that you're trying to compare U-wind to Wind Speed really
> shouldn't matter at all. The MET code doesn't really care... it's
all just
> numbers to the code. So it really comes down to getting it
configured well
> to make the type of comparisons you'd like to make. And the
DEBUG(3)
> counts of reason codes is the best way of indicating why obs aren't
being
> used.
>
> FYI, I'll be at NRL 7/29 - 8/2 for the METplus tutorial. So if we
haven't
> solved it by then, we can certainly figure it out that week.
>
> Thanks,
> John
>
> On Thu, Jul 18, 2019 at 5:41 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> >
> > Thanks for the example.
> >
> > Am I understanding that the obs_valid_beg and obs_valid_end
parameters
> > make all obs (in this example) in your netCDF file that fall
between 2000
> > and 2020 are valid candidates for comparison against the wind
speed
> field?
> >
> > I have been trying to get some matched pairs using my data set but
to no
> > avail... even when I use SYNOP as surface message type. I think
it might
> > just be my data that isn't matching.... after all I am comparing U
> > component of wind to wind speed obs so these values probably don’t
come
> > close to each other. Can you recommend any debugging method I can
use to
> > help focus in on what might be responsible for not getting matched
pairs
> > (or to confirm that it is indeed just a mismatch in forecast vs
obs)?
> >
> > Thanks,
> > Justin
> >
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, July 15, 2019 12:38 PM
> > To: Tsu, Mr. Justin
> > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> >
> > Justin,
> >
> > In a word, yes, adding "SYNOP" to the SURFACE entry of the
> > message_type_group_map tells Point-Stat to interpret observations
of that
> > type as existing at the surface. And when verifying against
surface obs,
> > Point-Stat skips over the logic of checking to make sure the
vertical
> level
> > matches.
> >
> > I know that sending data from NRL can be difficult, so I posted an
> example
> > on our ftp site. I'm running this Point-Stat command:
> >
> > *met-8.1/bin/point_stat \*
> > *PYTHON_NUMPY \*
> > *sample_pb.nc <http://sample_pb.nc> PointStatConfig \*
> > *-outdir out -v 3 -obs_valid_beg 20000101 -obs_valid_end 20200101*
> >
> > This just uses some sample obs that include wind speed from the
MET
> build.
> > That's why I set the matching time window to be 20 years (from
2000 to
> > 2020)... just to make sure we get matches.
> >
> > In the config file, I'm comparing 10-m wind from Python to wind
speed
> > observations of type ADPUPA. And that produces 0 matched pairs:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *fcst = { field = [ { 'name="read_NRL_binary.py
> > wndspd_zht_0010.0_0000.0_glob360x181_2016122412_01200000_fcstfld";
}
> > ];}obs = { field = [ { name = "WIND"; level = [ "Z10" ]; }
];}*
> > *message_type = [ "ADPUPA" ];*
> >
> >
> >
> >
> >
> > *DEBUG 3: Number of matched pairs = 0DEBUG 3: Observations
processed =
> > 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> > mismatch = 8077DEBUG 3: Rejected: message type = 4522*
> >
> > So then I tried what you're doing, adding ADPUPA to the list of
SURFACE
> > message types:
> >
> >
> > *message_type_group_map = [ { key = "SURFACE"; val =
> > "ADPSFC,SFCSHP,MSONET,ADPUPA"; },*
> > *...*
> >
> > And when I rerun, I do now get matched pairs:
> >
> >
> >
> >
> >
> > *DEBUG 3: Number of matched pairs = 5745DEBUG 3: Observations
processed
> > = 87753DEBUG 3: Rejected: obs type = 75154DEBUG 3: Rejected:
level
> > mismatch = 2332DEBUG 3: Rejected: message type = 4522*
> >
> > So adding ADPUPA to that list of SURFACE obs produces the desired
result.
> > Beware though that this doesn't actually make sense scientifically
for
> this
> > data. The ADPUPA obs really are upper-air sounding observations,
not
> > surface.
> >
> > If your obs really are at the surface, adding "SYNOP" to the list
SURFACE
> > message types should enable them to match. I posted my testing
files
> here:
> >
> > ftp://ftp.rap.ucar.edu/incoming/irap/met_help/tsu_data_20190715/
> >
> > Hope this example helps get you going.
> >
> > Thanks,
> > John
> >
> >
> > On Fri, Jul 12, 2019 at 5:05 PM Tsu, Mr. Justin via RT <
> met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730 >
> > >
> > > Thanks John,
> > >
> > > My message type in my observation file is 'SYNOP' so I've
changed the
> > > message_type and message_group_type to SYNOP (SURFACE=SYNOP).
Still
> > > getting 0
> > > matched pairs.
> > >
> > > Can you explain to me how point_stat uses the configuration
file's
> > > definition
> > > of message_type=surface to compare with the forecast? You've
already
> > > explained to me that by providing point_Stat with a zht_10 UWIND
field,
> > > point_Stat automatically considers this surface data; hence, my
> forecast
> > > is
> > > at the surface. Now, when I put message_type=SYNOP (and
> SURFACE={SYNOP}
> > > in
> > > message_group_type), does point_stat now consider my obs to be
at the
> > > surface?
> > > At this point, are my obs and fcst at the same vertical level
in the
> MET
> > > domain?
> > >
> > > Justin
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Friday, July 12, 2019 3:30 PM
> > > To: Tsu, Mr. Justin
> > > Subject: Re: [rt.rap.ucar.edu #90730] Questions about point_stat
> > >
> > > Justin,
> > >
> > > The message_type is an attribute of the observations. So it
only needs
> > to
> > > appear in the "obs" dictionary. But having it in the "fcst"
dictionary
> > as
> > > well should have no effect. The ADPSFC message type indicates
to MET
> > that
> > > the observations occur at the surface... that's their special
meaning.
> > >
> > > Yes, looking at the counts I see that most are being discard
because
> they
> > > don't match the requested message type (12515) and others are
off your
> > > model domain (1565):
> > >
> > > DEBUG 3: Observations processed = 14080
> > > DEBUG 3: Rejected: obs type = 12515
> > > DEBUG 3: Rejected: off the grid = 1565
> > >
> > > So you just need to take a look at how the point observations
are
> encoded
> > > in the point observation NetCDF file:
> > > sfc_2019042612.nc
> > >
> > > If you have access to R, you can dump those to ascii which is
more
> > > readable, by running:
> > > Rscript
> > /software/depot/met/met-
8.0_bugfix/share/met/Rscripts/pntnc2ascii.R
> > > sfc_2019042612.nc > sfc_2019042612.txt
<http://sfc_2019042612.nc>
> > >
> > > Do you actually have ADPSFC message types in there? And if so,
do they
> > > actually fall inside your model domain?
> > >
> > > MET's plot_point_obs tool can be helpful in answering these
questions,
> > but
> > > since you're using Python embedding, that complicates things a
bit.
> > >
> > > Let me know what additional questions you have.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Fri, Jul 12, 2019 at 2:13 PM Tsu, Mr. Justin via RT <
> > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
>
> > > >
> > > > Hi John,
> > > >
> > > > Thank you for your descriptive response and apologies for the
> delay. I
> > > > got
> > > > caught up in some other work.
> > > >
> > > > I am investigating the second method you proposed which was to
use
> > > ADPSFC.
> > > > Couple questions here:
> > > >
> > > > 1. Does ADPSFC have any meaning other than to use it as a
reference
> to
> > > > link
> > > > obs and fcst to the same message group type (SURFACE)?
> > > >
> > > > 2. Is ADPSFC an ob only designation of message_type? Or am I
supposed
> > to
> > > > assign message_type ADPSFC to both obs and fcst dictionaries?
> > > >
> > > > I ended up testing message_type=ADPSFC for both obs and fcst
to test
> it
> > > > out:
> > > >
> > > > 73 fcst = {
> > > > 74
> > > > 75
> > > > 76 field = [
> > > > 77 {
> > > > 78 name = "/users/tsu/MET/work/read_NRL_binary.py
> > > >
uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld";
> > > > 79 message_type = ["ADPSFC"];
> > > > 80 }
> > > > 81
> > > > 82 ];
> > > > 83
> > > > 84 }
> > > > 85
> > > > 86 obs = {
> > > > 87 field = [
> > > > 88 {
> > > > 89 file_type = NETCDF_NCCF;
> > > > 90 name = "ws";
> > > > 91 level = ["P975-P1000"];
> > > > 92 message_type = ["ADPSFC"];
> > > > 93 }
> > > > 94 ];
> > > > 95 }
> > > >
> > > > If I am understanding your message correctly, if I set the
message
> > types
> > > > of
> > > > both fcst and obs to ADPSFC, point_stat will ignore the
> > > > height/level/elevation
> > > > columns of my observations and my forecast field and just
compare as
> is
> > > > with
> > > > necessary horizontal interpolation. Is this correct?
> > > >
> > > > Either way, running it this way gives me 0 matched pairs...
> > > >
> > > > point_stat PYTHON_NUMPY sfc_2019042612.nc config.rc -v 3
> > > > DEBUG 1: Default Config File:
> > > >
> > >
> >
> /software/depot/met/met-
8.0_bugfix/share/met/config/PointStatConfig_default
> > > > DEBUG 1: User Config File: config.rc
> > > > GSL_RNG_TYPE=mt19937
> > > > GSL_RNG_SEED=99166301
> > > > DEBUG 1: Forecast File: PYTHON_NUMPY
> > > > DEBUG 1: Observation File: sfc_2019042612.nc
> > > > Input File:
> > > >
'uuwind_zht_000010_000000_1a0075x0073_2019042612_00000000_fcstfld'
> > > > Data Shape: (73, 75)
> > > > Data Type: dtype('float64')
> > > > Data Range: -5.4485907554626465 to 11.497947692871094
> > > > Attributes: {'long_name': 'UNKNOWN', 'init':
'20190426_120000',
> > 'valid':
> > > > '20190426_120000', 'grid': {'scale_lat_2': 30.0, 'hemisphere':
'N',
> > > > 'scale_lat_1': 60.0, 'lon_pin': 236.0, 'lat_pin': 38.0,
'name':
> 'COAMPS
> > > > Test
> > > > Grid', 'x_pin': 38.0, 'lon_orient': 238.0, 'y_pin': 37.0,
'nx': 75,
> > 'ny':
> > > > 73,
> > > > 'r_km': 6361.2, 'type': 'Lambert Conformal', 'd_km': 27.0},
'name':
> > > > 'uuwind',
> > > > 'lead': '0', 'level': 'zht_000010', 'units': 'UNKNOWN',
'accum':
> '00'}
> > > > DEBUG 2:
> > > > DEBUG
> > > > 2:
> > > >
> > >
> >
>
--------------------------------------------------------------------------------
> > > > DEBUG 2:
> > > > DEBUG 2: Reading data for uuwind/zht_000010.
> > > > DEBUG 3: Use the forecast grid.
> > > > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 75
Ny: 73
> > > > Lat_LL:
> > > > 30.190 Lon_LL: -105.630 Lon_orient: 122.000 Alpha: 422.437
Cone:
> 0.716
> > > Bx:
> > > > 283.3939 By: -23.3975
> > > > DEBUG 2: Processing masking regions.
> > > > DEBUG 3: Processing grid mask: FULL
> > > > DEBUG 2: For uuwind/zht_000010 found 1 forecast levels, 0
climatology
> > > mean
> > > > levels, and 0 climatology standard deviation levels.
> > > > DEBUG 2:
> > > > DEBUG
> > > > 2:
> > > >
> > >
> >
>
--------------------------------------------------------------------------------
> > > > DEBUG 2:
> > > > DEBUG 2: Searching 14080 observations from 1800 messages.
> > > > DEBUG 2:
> > > > DEBUG
> > > > 2:
> > > >
> > >
> >
>
--------------------------------------------------------------------------------
> > > > DEBUG 2:
> > > > DEBUG 2: Processing uuwind/zht_000010 versus ws/Z10, for
observation
> > type
> > > > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using
> 0
> > > > pairs.
> > > > DEBUG 3: Number of matched pairs = 0
> > > > DEBUG 3: Observations processed = 14080
> > > > DEBUG 3: Rejected: SID exclusion = 0
> > > > DEBUG 3: Rejected: obs type = 12515
> > > > DEBUG 3: Rejected: valid time = 0
> > > > DEBUG 3: Rejected: bad obs value = 0
> > > > DEBUG 3: Rejected: off the grid = 1565
> > > > DEBUG 3: Rejected: level mismatch = 0
> > > > DEBUG 3: Rejected: quality marker = 0
> > > > DEBUG 3: Rejected: message type = 0
> > > > DEBUG 3: Rejected: masking region = 0
> > > > DEBUG 3: Rejected: bad fcst value = 0
> > > > DEBUG 3: Rejected: duplicates = 0
> > > > DEBUG 2:
> > > > DEBUG
> > > > 2:
> > > >
> > >
> >
>
--------------------------------------------------------------------------------
> > > > DEBUG 2:
> > > > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V.stat
> > > > DEBUG 1: Output file:
./point_stat_000000L_20190426_120000V_cnt.txt
> > > >
> > > >
> > > > Justin
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Friday, June 21, 2019 12:59 PM
> > > > To: Tsu, Mr. Justin
> > > > Subject: Re: [rt.rap.ucar.edu #90730] Questions about
point_stat
> > > >
> > > > Hi Justin,
> > > >
> > > > I see you have a question about using Python embedding in
Point-Stat.
> > So
> > > > you're passing a single forecast field of 10 m wind to Point-
Stat and
> > > want
> > > > to compare it to point observations. But your point
observations are
> > in
> > > > pressure, not height.
> > > >
> > > > Here's some information which applies to this situation...
> > > >
> > > > First, Point-Stat does not do any conversion of pressure to
height
> for
> > > you,
> > > > or vice versa. However, typically point observations include
both a
> > > height
> > > > above ground and a pressure level. For example, the ascii2nc
tool in
> > MET
> > > > can read a simple 11-column ascii point observation format:
> > > > The "met_point" ASCII format consists of 11 columns:
> > > > Message_Type Station_ID
Valid_Time(YYYYMMDD_HHMMSS)
> > > > Lat(Deg North) Lon(Deg East) Elevation(msl)
> > > > Var_Name(or GRIB_Code) Level Height(msl or
agl)
> > > > QC_String Observation_Value
> > > > For a sounding, the pressure level is listed in the "Level"
column
> and
> > > the
> > > > height is listed in the "Height" column. Take a look at the
point
> > > > observations you're using to see if you have both height and
pressure
> > > > listed.
> > > >
> > > > Second, typically, 2-m temperature and 10-m winds are
considered to
> be
> > > > forecasts at the "surface". Adopting the logic from NCEP's
> > verification
> > > > package, on which MET was originally based, the matching for
surface
> > > fields
> > > > is done by the message type, not the actual vertical level.
For
> > example,
> > > > let's say you're verifying 2-m temperature (name = "TMP";
level =
> > "Z2";)
> > > > and you're verifying it against the ADPSFC message type (land
surface
> > > > observations). Point-Stat doesn't actually check the height
of the
> > > > observation to make sure it's exactly 2. Instead, all ADPSFC
> > > observations
> > > > are automatically used since they are assumed to live at the
surface.
> > > Take
> > > > a look at the PointStatConfig file, the "message_type_group"
map's
> > entry
> > > > for "SURFACE" defines the message types for which this logic
should
> be
> > > > applied:
> > > >
> > > > //
> > > > // Mapping of message type group name to comma-separated list
of
> > values.
> > > > //
> > > > message_type_group_map = [
> > > > { key = "SURFACE"; val = "ADPSFC,SFCSHP,MSONET";
},
> > > > { key = "ANYAIR"; val = "AIRCAR,AIRCFT";
},
> > > > { key = "ANYSFC"; val =
"ADPSFC,SFCSHP,ADPUPA,PROFLR,MSONET"; },
> > > > { key = "ONLYSF"; val = "ADPSFC,SFCSHP";
},
> > > > { key = "LANDSF"; val = "ADPSFC,MSONET";
},
> > > > { key = "WATERSF"; val = "SFCSHP";
}
> > > > ];
> > > >
> > > > Third, there are many ways to configure Point-Stat to control
what
> > range
> > > of
> > > > vertical levels are used in the verification, both in the
forecast
> and
> > > > observation data sources. For example, let's say you're
verifying
> > 500mb
> > > > temperature against upper-air observations. Here's 3 ways you
could
> > > > configure it:
> > > >
> > > > (1) Single forecast field versus single observation level:
> > > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > > obs = fcst;
> > > >
> > > > (2) Single forecast field versus range of observation levels:
> > > > fcst = { field = [ { name = "TMP"; level = "P500"; } ]; }
> > > > obs = { field = [ { name = "TMP"; level = "P475-525"; } ]; }
> > > >
> > > > (3) Range of forecast fields versus range of observation
levels:
> > > > fcst = { field = [ { name = "TMP"; level = "P400-600"; } ]; }
> > > > obs = { field = [ { name = "TMP"; level = "P450-550"; } ]; }
> > > >
> > > > In (1) and (2), we do not vertical interpolation of the
forecast data
> > > since
> > > > you've only requested a single level. In (3), we'll read data
for
> 400,
> > > > 500, and 600 mb levels, but only use obs falling between 450
and 550.
> > > For
> > > > each obs, we'll vertically interpolate the forecast values
from the
> > > levels
> > > > above/below it to the actual pressure level of the obs.
> > > >
> > > > So lots of configuration options.
> > > >
> > > > If that answers your question, then great. If not, you could
send me
> > > some
> > > > sample data with a description of what you're trying to do,
and I can
> > run
> > > > it here.
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > >
> > > >
> > > > On Thu, Jun 20, 2019 at 3:30 PM Tsu, Mr. Justin via RT <
> > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > Thu Jun 20 15:30:54 2019: Request 90730 was acted upon.
> > > > > Transaction: Ticket created by justin.tsu at nrlmry.navy.mil
> > > > > Queue: met_help
> > > > > Subject: Questions about point_stat
> > > > > Owner: Nobody
> > > > > Requestors: justin.tsu at nrlmry.navy.mil
> > > > > Status: new
> > > > > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90730
> > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > > I'm trying to use python embedding within point stat to
verify a
> > model
> > > > > field
> > > > > of wind at 10 m using raobs whose positions are in pressure.
Is
> > there
> > > a
> > > > > value in the config file that I need to set so that
point_Stat
> knows
> > to
> > > > > interpolate to a common height between meter and pressure?
Because
> > > right
> > > > > now
> > > > > I'm getting 0 matched pairs when I run point_stat
> > > > >
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > >
> > > > >
> > > > > Justin Tsu
> > > > >
> > > > > Marine Meteorology Division
> > > > >
> > > > > Data Assimilation/Mesoscale Modeling
> > > > >
> > > > > Building 704 Room 212
> > > > >
> > > > > Naval Research Laboratory, Code 7531
> > > > >
> > > > > 7 Grace Hopper Avenue
> > > > >
> > > > > Monterey, CA 93943-5502
> > > > >
> > > > >
> > > > >
> > > > > Ph. (831) 656-4111
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
More information about the Met_help
mailing list