[Met_help] [rt.rap.ucar.edu #96043] History for success in generating masking files, but not uploading to metviewer
John Halley Gotway via RT
met_help at ucar.edu
Mon Aug 3 11:52:45 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Since the last time we talked, I managed to generate 19 individual masking
files based on the VGTYP field. I examined each file individually and they
looked reasonable. I incorporated this into my workflow so that these
files are generated each day. The reason for doing that is because
throughout the year, the VGTYP is expected to change, particularly in the
long-term. I have a line in my master script that calls this routine like
so:
1.
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/scripts/Mask_Maker.sh
LAND"
LAND is the input because I'm using a land mask to generate these files. In
the future I may use different masks depending on the goals of the
verification package.
When step 1. is run, the data is stored here:
2.
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/yyyymmdd".
I've adjusted my PointStatConfig_cam file (located here:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/parm/met_config).
You can see that I've added 19 additional files based on the above location
in step 2.
3. "mask = {
// grid = [ "G236", "G245", "G246" ];
poly = [ "MET_BASE/poly/CONUS.poly",
"MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
"MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
"MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
"MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
"MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
"MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
"MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
"MET_BASE/poly/APL.poly", "${MET_PLUS}/polydata/land_mask/${DATE}/
land_mask_0.nc", "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_1.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_2.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_3.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_4.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_5.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_6.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_7.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_8.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_9.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_10.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_11.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_12.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_13.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_14.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_15.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_16.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_17.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_18.nc" ];"
Running my PB2NC, PointStat, and StatAnalysis is successful when including
these steps. In fact, I thought that because the steps ran to completion,
that my stat files would have additional output specific to the land
masks. Following the naming convention of the poly files, I figured that I
would have land_mask_XX in the stat files under VX_MASK. However, when
looking in these files I do not have any additional masked regions. When
searching in the log file for the land_mask output, I find messages saying
this:
4.
DEBUG 4: VarInfoFactory::new_var_info() -> created new VarInfo object of
type "FileType_NcMet".
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200725/
land_mask_6.nc
DEBUG 4: parse_poly_mask() -> parsing poly mask
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200725/
land_mask_6.nc"
DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
Met2dDataFile object of type "FileType_NcMet".
DEBUG 4:
DEBUG 4: Lambert Conformal Grid Data:
DEBUG 4: hemisphere: N
DEBUG 4: scale_lat_1: 33
DEBUG 4: scale_lat_2: 45
DEBUG 4: lat_pin: 21.017
DEBUG 4: lon_pin: 123.282
DEBUG 4: x_pin: 0
DEBUG 4: y_pin: 0
DEBUG 4: lon_orient: 97
DEBUG 4: d_km: 12
DEBUG 4: r_km: 6371.2
DEBUG 4: nx: 468
DEBUG 4: ny: 288
DEBUG 4: so2_angle: 0
DEBUG 4:
The printout is consistent between masks with all specifications under
Lambert Conformal Grid Data being the same for all 19 new masked regions.
There is an indication that a new file was created, but it's not clear
where the file is or the name of the file. I've looked in the poly files
for the regions that work and the lat/lons are clearly listed in column
format for those regions with the region name at the very top of that
file. I know that met does a lot under the hood, so I'm wondering if and
how met can process the netcdf files I've created using gen_vx_mask. I
assume it knows how to handle these files. If I can successfully generate
files with stats on each land mask type - 19 in all - then I can do
surface-type based statistics, which will be really valuable down the road.
RegridDataPlane:
It's become clear to me that I will also need to run RegridDataPlane to
match the grid for PM and O3 with that of the meteorology files. Both the
datasets are stored in the same directory since the meteorology drives CMAQ
output for ozone and pm, as well as other chemical species. To properly
validate meteorological impacts, I need to take PM and Ozone and put them
on the same grid. They are both Lambert Conformal grids, but the shape of
the matrix is different between the two: 1) meteorology output (288, 468)
and 2) pm/ozone output (265, 442). I understand how I would need to use
RegridDataPlane for the most part, but I see from an example that a special
file may need to be required that has grid specific information. I only
assume this based on an online example where this is used:
REGRID_DATA_PLANE_VERIF_GRID={INPUT_BASE}/met_test/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
I don't see any file with a G212 (or GXXX) extension in the output, so I'm
wondering what file I would need to use. I think that if I know what to
put for REGRID_DATA_PLANE_VERIF_GRID, then I should be good with
configuring RegridDataPlane. I just simply want to use the grid from the
meteorological files (e.g.
/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00) and regrid
the pm and ozone files to the that grid (e.g. of pm file:
/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.pm25.f36.148.grib). I
would store the new output file in a predesignated location that would be
used for evaluating meteorological/PBL impacts conditioned on surface type.
Thanks in advance for your guidance. Please let me know if there is
additional info that is needed. I hope that I was clear enough about the
intended goals.
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Julie Prestopnik
Time: Tue Jul 28 11:59:31 2020
Hi Edward.
I see that you have some masking questions and questions about
RegridDataPlane. I am assigning this ticket to John Halley Gotway.
Please
allow a few business days for a response.
Julie
On Tue, Jul 28, 2020 at 10:22 AM Edward Strobach - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> Tue Jul 28 10:22:33 2020: Request 96043 was acted upon.
> Transaction: Ticket created by edward.strobach at noaa.gov
> Queue: met_help
> Subject: success in generating masking files, but not uploading
to
> metviewer
> Owner: Nobody
> Requestors: edward.strobach at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
>
>
> Since the last time we talked, I managed to generate 19 individual
masking
> files based on the VGTYP field. I examined each file individually
and they
> looked reasonable. I incorporated this into my workflow so that
these
> files are generated each day. The reason for doing that is because
> throughout the year, the VGTYP is expected to change, particularly
in the
> long-term. I have a line in my master script that calls this
routine like
> so:
>
> 1.
>
>
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/scripts/Mask_Maker.sh
> LAND"
>
> LAND is the input because I'm using a land mask to generate these
files. In
> the future I may use different masks depending on the goals of the
> verification package.
>
> When step 1. is run, the data is stored here:
> 2.
>
>
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/yyyymmdd".
>
> I've adjusted my PointStatConfig_cam file (located here:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/parm/met_config).
> You can see that I've added 19 additional files based on the above
location
> in step 2.
>
> 3. "mask = {
> // grid = [ "G236", "G245", "G246" ];
> poly = [ "MET_BASE/poly/CONUS.poly",
> "MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
> "MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
> "MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
> "MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
> "MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
> "MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
> "MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
> "MET_BASE/poly/APL.poly", "${MET_PLUS}/polydata/land_mask/${DATE}/
> land_mask_0.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_1.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_2.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_3.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_4.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_5.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_6.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_7.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_8.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_9.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_10.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_11.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_12.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_13.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_14.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_15.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_16.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_17.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_18.nc" ];"
>
> Running my PB2NC, PointStat, and StatAnalysis is successful when
including
> these steps. In fact, I thought that because the steps ran to
completion,
> that my stat files would have additional output specific to the land
> masks. Following the naming convention of the poly files, I figured
that I
> would have land_mask_XX in the stat files under VX_MASK. However,
when
> looking in these files I do not have any additional masked regions.
When
> searching in the log file for the land_mask output, I find messages
saying
> this:
>
> 4.
> DEBUG 4: VarInfoFactory::new_var_info() -> created new VarInfo
object of
> type "FileType_NcMet".
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200725/
> land_mask_6.nc
> DEBUG 4: parse_poly_mask() -> parsing poly mask
>
>
"/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200725/
> land_mask_6.nc"
> DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
> Met2dDataFile object of type "FileType_NcMet".
> DEBUG 4:
> DEBUG 4: Lambert Conformal Grid Data:
> DEBUG 4: hemisphere: N
> DEBUG 4: scale_lat_1: 33
> DEBUG 4: scale_lat_2: 45
> DEBUG 4: lat_pin: 21.017
> DEBUG 4: lon_pin: 123.282
> DEBUG 4: x_pin: 0
> DEBUG 4: y_pin: 0
> DEBUG 4: lon_orient: 97
> DEBUG 4: d_km: 12
> DEBUG 4: r_km: 6371.2
> DEBUG 4: nx: 468
> DEBUG 4: ny: 288
> DEBUG 4: so2_angle: 0
> DEBUG 4:
>
> The printout is consistent between masks with all specifications
under
> Lambert Conformal Grid Data being the same for all 19 new masked
regions.
> There is an indication that a new file was created, but it's not
clear
> where the file is or the name of the file. I've looked in the poly
files
> for the regions that work and the lat/lons are clearly listed in
column
> format for those regions with the region name at the very top of
that
> file. I know that met does a lot under the hood, so I'm wondering
if and
> how met can process the netcdf files I've created using gen_vx_mask.
I
> assume it knows how to handle these files. If I can successfully
generate
> files with stats on each land mask type - 19 in all - then I can do
> surface-type based statistics, which will be really valuable down
the road.
>
> RegridDataPlane:
> It's become clear to me that I will also need to run RegridDataPlane
to
> match the grid for PM and O3 with that of the meteorology files.
Both the
> datasets are stored in the same directory since the meteorology
drives CMAQ
> output for ozone and pm, as well as other chemical species. To
properly
> validate meteorological impacts, I need to take PM and Ozone and put
them
> on the same grid. They are both Lambert Conformal grids, but the
shape of
> the matrix is different between the two: 1) meteorology output
(288, 468)
> and 2) pm/ozone output (265, 442). I understand how I would need to
use
> RegridDataPlane for the most part, but I see from an example that a
special
> file may need to be required that has grid specific information. I
only
> assume this based on an online example where this is used:
>
>
>
REGRID_DATA_PLANE_VERIF_GRID={INPUT_BASE}/met_test/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>
> I don't see any file with a G212 (or GXXX) extension in the output,
so I'm
> wondering what file I would need to use. I think that if I know
what to
> put for REGRID_DATA_PLANE_VERIF_GRID, then I should be good with
> configuring RegridDataPlane. I just simply want to use the grid
from the
> meteorological files (e.g.
> /gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00) and
regrid
> the pm and ozone files to the that grid (e.g. of pm file:
>
/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.pm25.f36.148.grib).
I
> would store the new output file in a predesignated location that
would be
> used for evaluating meteorological/PBL impacts conditioned on
surface type.
>
> Thanks in advance for your guidance. Please let me know if there is
> additional info that is needed. I hope that I was clear enough
about the
> intended goals.
>
> --
> Edward Strobach
> EMC/NCEP/NWS/
> IMSG Contractor
> Cubicle#: 2029
> 301-683-3717
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Wed Jul 29 17:12:24 2020
Ed,
Sorry for the delay Ed. I had hoped to get to this today but ran out
of
time. I'll take a look tomorrow. Just wanted to let you know that I
haven't
forgotten about it.
Thanks,
John
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Edward Strobach - NOAA Affiliate
Time: Thu Jul 30 15:38:26 2020
No worries, and thanks for the update.
On Wed, Jul 29, 2020 at 7:12 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Ed,
>
> Sorry for the delay Ed. I had hoped to get to this today but ran out
of
> time. I'll take a look tomorrow. Just wanted to let you know that I
haven't
> forgotten about it.
>
> Thanks,
> John
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Thu Jul 30 16:57:34 2020
Ed,
I see that you were able to make some progress. That's interesting
that
you're regenerating them each day. This sounds similar to what Logan
Dawson
from NOAA/EMC is doing in the verifying daily precip warning areas. He
runs
gen_vx_mask each day to define masking regions from shapefiles (from
WPC I
think?). So the regions change each day. I'm glad to hear that logic
is
working.
Thanks for sending your mask config file entries. I have a couple of
suggestions.
(1) Since those CONUS and sub-region polylines remain fixed, it'd be
more
efficient to run them through gen_vx_mask, generate NetCDF output for
your
domain, and list the NetCDF mask files there instead. Using the .poly
files
does work, but every time you run, Point-Stat wastes time figuring out
which points are inside/outside each region. For a coarse grid, the
difference may not be noticeable, but for something like the HRRR
grid, it
could be significant.
The downside is that if you change verification domains, you should
regenerate those NetCDF mask files.
(2) Conversely, if generating those 19 extra NetCDF mask files each
day for
the VGTYP data is too much overhead, you could do this simple data
masking
directly in the config file. For example, let's say you've set an
environment variable FCST_FILE = path to your current input data file.
You
could define:
mask = {
// grid = [ "G236", "G245", "G246" ];
poly = [ ...
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq0",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq1",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq2",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq3",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq4",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq5",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq6",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq7",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq8",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq9",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq10",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq11",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq12",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq13",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq14",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq15",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq16",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq17",
"${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq18"
];
That'll define your 19 masks by applying the threshold we've listed
for
each. The downside is that you'll have no control over how the VX_MASK
is
named. You'll get some unique string, but you won't be able to modify
it.
I'm not sure if this would be any faster, but then you wouldn't need
to
generate all those extra NetCDF files each day.
But getting on the specific question you asked...
So you ran Point-Stat using these extra 19 masking regions And the log
messages from Point-Stat indicate that it's reading data from those
mask
files. But you see no output data for VX_MASK = land_mask_*.
It's important to note that if Point-Stat found 0 matched pairs for a
particular masking region, then nothing will be written to the output
file.
Typically, I'd recommend looking at the verbosity level 3 log messages
from
Point-Stat to figure out how many matched pairs were used... and why
they
were excluded. So if you have the Point-Stat log files, please take a
look
at that info.
I took a look at the VGTYP masks and see that some of them are pretty
sparse... only a handful of points spread out across the grid.
In your Point-Stat config file, I see you're currently using bilinear
interpolation... which uses the 4 closest points. If any of those 4
nearby
points is NOT in the current masking region, then the interpolated
forecast
value will be set to bad data... so no matched pair.
To test this, please try re-configuring and re-running Point-Stat
using
both bilinear and nearest neighbor interpolation. Then check to see if
you
get any land_mask_* output.
//
// Interpolation methods
//
interp = {
vld_thresh = 1.0;
type = [
{ method = BILIN; width = 2; },
{ method = NEAREST; width = 1; }
];
}
With nearest neighbor interpolation, I would think that you'd get some
land_mask_* output! This highlights the point that masking regions are
applied to the gridded forecast data... not the point observations
themselves. Please let me know what you figure out.
In regards to regrid_data_plane, yes, data must be put onto a common
grid
to be compared. And yes, you could use regrid_data_plane to do that.
Alternatively, you can do this regridding directly in the MET
configuration
files. That avoids the need to run regrid_data_plane at all. But there
are
pros and cons.
First, let me say how to do this. In the Grid-Stat config file, note
the
"regrid" section:
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/GridStatConfig_default#L31
And here's a description of how to configure those options:
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/README#L353
In your case, you could regrid both the forecast and obs data to a
common
grid by setting:
regrid = {
to_grid =
"/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00";
method = BILIN;
width = 2;
vld_thresh = 0.5;
shape = SQUARE;
}
I listed bilinear interpolation, but it's up to you to decide how they
should be regridded.
The advantage to regridding directly in the config file is that it's
convenient and you don't need to write extra data files. The downside
is
that if you're regridding the same data multiple times, then that's
less
efficient. For example, let's say you have obs data that you're
verifying
against 10 different forecast lead times, all valid for that same
time. If
you regrid in the config file like this, then you're regridding the
same
obs data 10 times. It would be more efficient to do it once using
regrid_data_plane and read it's output into Grid-Stat.
So that's up to you to weigh the convenience against the efficiency.
Just
ask yourself if and how many times you're regridding the same
datasets.
Hope that helps.
Thanks,
John
On Wed, Jul 29, 2020 at 5:12 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Ed,
>
> Sorry for the delay Ed. I had hoped to get to this today but ran out
of
> time. I'll take a look tomorrow. Just wanted to let you know that I
haven't
> forgotten about it.
>
> Thanks,
> John
>
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Edward Strobach - NOAA Affiliate
Time: Fri Jul 31 09:37:45 2020
Hi John,
Thanks for the suggestions to improve efficiency. I shall look into
that
once I can get the immediate issue squared away.
I agree with you that many of the masked regions that have been
created
will not have nearby observations that can be used for validation.
However, some of the masked regions are quite large. Look at the
attached
plot for example, which I believe was from the land_mask_11.nc file.
You
can see that there is a considerable amount of coverage over CONUS
from
this particular masked region. I would have expected at least
something
based on the coverage of both this region and obs.
I have gone ahead and added the nearest neighbor interpolation. I had
intended to do that anyways since I thought it would be more
appropriate
for this kind of field, especially since the ozone and pm fields may
not
always be continuous, and thus more local in nature.
As recommended, I changed the verbosity for point stat to 3 in order
to
examine matched pairs to see if any of the masks were selected.
It does appear that all of these files are being examined to see if
there
are matched pairs. I had to take a look carefully because I
originally
assumed that I would be looking for land_mask_XX when searching for
matched
pairs. My thinking was that the masks would be named based on the
name of
the file. It turns out that it uses the name within the file. The
poly
files have the regions listed at the top while the name in the netcdf
files
is data_mask for all files. That may be a problem later on since I'll
ultimately want to distinguish these regions based on a clearly
written
name that distinguishes regions. As you can see all masked regions
are
being processed, but despite including nearest neighbor interpolation,
I
still get 0 matched pairs.
DEBUG 2: Reading data for TMP/Z2.
DEBUG 3: Use the matching forecast and observation grids.
DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 468 Ny:
288
Lat_LL: 21.017 Lon_LL: 123.282 Lon_orient: 97.000 Alpha: 1037.975
Cone:
0.630 Bx: 233.6421 By: 785.2276
DEBUG 2: Processing masking regions.
DEBUG 3: Processing grid mask: G236
DEBUG 3: Processing poly mask: MET_BASE/poly/CONUS.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/NEC.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/SEC.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/NWC.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/SWC.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/NMT.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/SMT.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/GRB.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/SWD.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/NPL.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/SPL.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/MDW.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/LMV.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/GMC.poly
DEBUG 3: Processing poly mask: MET_BASE/poly/APL.poly
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_0.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_1.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_2.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_3.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_4.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_5.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_6.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_7.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_8.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_9.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_10.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_11.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_12.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_13.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_14.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_15.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_16.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_17.nc
DEBUG 3: Processing poly mask:
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
land_mask_18.nc
DEBUG 2: Processing geography data.
For example, the GMC region has 496
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type ONLYSF,
over
region GMC, for interpolation method BILIN(4), using 496 matched
pairs.
DEBUG 3: Number of matched pairs = 496
DEBUG 3: Observations processed = 41207
DEBUG 3: Rejected: station id = 0
DEBUG 3: Rejected: obs type = 35085
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 397
DEBUG 3: Rejected: topography = 0
DEBUG 3: Rejected: level mismatch = 0
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 0
DEBUG 3: Rejected: masking region = 5229
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: bad climo mean = 0
DEBUG 3: Rejected: bad climo stdev = 0
DEBUG 3: Rejected: duplicates = 0
DEBUG 2: Computing Categorical Statistics.
DEBUG 2: Computing Scalar Partial Sums and Continuous Statistics.
While, this example of data_mask (as well as the 18 others) have 0
matched
pairs.
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type ONLYSF,
over
region data_mask, for interpolation method BILIN(4), using 0 matched
pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 41207
DEBUG 3: Rejected: station id = 0
DEBUG 3: Rejected: obs type = 35085
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 397
DEBUG 3: Rejected: topography = 0
DEBUG 3: Rejected: level mismatch = 0
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 0
DEBUG 3: Rejected: masking region = 5725
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: bad climo mean = 0
DEBUG 3: Rejected: bad climo stdev = 0
DEBUG 3: Rejected: duplicates = 0
So, for ONLYSF, there are written out statements for 2-m temperature
in
accordance with the two interpolation options listed. Again, I'm a
bit
surprised that 0 matched pairs were found for all regions, especially
since
some regions, like the one attached below, have a decent amount of
coverage.
As for regridding data, I think I want to stick with running
RegridDataPlane. In the pointstat configure files, the ozone and pm
data
being generated are stored on the "FULL" cmaq grid, whereas the
meteorology
used to drive CMAQ is stored on a different grid. in the two
pointstat
files I use, I see
mask = {
grid = [ "FULL" ];
poly = [ "MET_BASE/poly/CONUS.poly", "MET_BASE/poly/EAST.poly",
"MET_BASE/poly/WEST.poly",
"MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
"MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
"MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
"MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
"MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
"MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
"MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
"MET_BASE/poly/APL.poly" ];
sid = [];
}
with grid set to FULL
and with the meteorology I see
mask = {
// grid = [ "G236", "G245", "G246" ];
poly = [ "MET_BASE/poly/CONUS.poly",
"MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
"MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
"MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
"MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
"MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
"MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
"MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
"MET_BASE/poly/APL.poly", "${MET_PLUS}/polydata/land_mask/${DATE}/
land_mask_0.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_1.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_2.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_3.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_4.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_5.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_6.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_7.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_8.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_9.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_10.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_11.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_12.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_13.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_14.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_15.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_16.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_17.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_18.nc" ];
grid = ${POINT_STAT_GRID};
// poly = ${POINT_STAT_POLY};
sid = [];
}
which specifies 3 separate grids. That confuses me a bit, to be
honest, so
it's hard for me to visualize how to configure regrid for remapping
the
ozone and pm being generated to the same grid as the meteorology.
I'll
ultimately want to remap to this grid so I can use the land mask files
for
pm and ozone as well. however, somehow, based on recent developments,
there doesn't seem to be any matched pairs. RegridDataPlane seems to
take
the obs and regrid it to match that of the forecast grid.
I think in my case I would set the following in RegridDataPlane:
OBS_REGRID_DATA_PLANE_RUN = False
FCST_REGRID_DATA_PLANE_RUN = True
I would list all fields and levels that I want regridded - pm and
ozone at the surface in this case - and specify a file
that contains the information about what grid I want to regrid to.
In the example online, there is this:
REGRID_DATA_PLANE_VERIF_GRID={INPUT_BASE}/met_test/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
I'm not exactly sure what's in that file, but I'm trying to see if I
could use an arbitrary file from the meteorology output:
aqm.t00z.nmm00.tm00
I'm wondering if met would know to take the lat/lons from this file
and convert the ozone and pm data to grid specified by the
lat lons in that file. If so, then I'm good. An alternative is to
get my federal oversight manager to create an action item for
item to regrid the land mask data onto the grid that the ozone and pm
is on.
On Thu, Jul 30, 2020 at 6:57 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Ed,
>
> I see that you were able to make some progress. That's interesting
that
> you're regenerating them each day. This sounds similar to what Logan
Dawson
> from NOAA/EMC is doing in the verifying daily precip warning areas.
He runs
> gen_vx_mask each day to define masking regions from shapefiles (from
WPC I
> think?). So the regions change each day. I'm glad to hear that logic
is
> working.
>
> Thanks for sending your mask config file entries. I have a couple of
> suggestions.
>
> (1) Since those CONUS and sub-region polylines remain fixed, it'd be
more
> efficient to run them through gen_vx_mask, generate NetCDF output
for your
> domain, and list the NetCDF mask files there instead. Using the
.poly files
> does work, but every time you run, Point-Stat wastes time figuring
out
> which points are inside/outside each region. For a coarse grid, the
> difference may not be noticeable, but for something like the HRRR
grid, it
> could be significant.
>
> The downside is that if you change verification domains, you should
> regenerate those NetCDF mask files.
>
> (2) Conversely, if generating those 19 extra NetCDF mask files each
day for
> the VGTYP data is too much overhead, you could do this simple data
masking
> directly in the config file. For example, let's say you've set an
> environment variable FCST_FILE = path to your current input data
file. You
> could define:
>
> mask = {
> // grid = [ "G236", "G245", "G246" ];
> poly = [ ...
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq0",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq1",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq2",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq3",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq4",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq5",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq6",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq7",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq8",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq9",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq10",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq11",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq12",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq13",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq14",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq15",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq16",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq17",
> "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq18"
> ];
>
> That'll define your 19 masks by applying the threshold we've listed
for
> each. The downside is that you'll have no control over how the
VX_MASK is
> named. You'll get some unique string, but you won't be able to
modify it.
>
> I'm not sure if this would be any faster, but then you wouldn't need
to
> generate all those extra NetCDF files each day.
>
> But getting on the specific question you asked...
>
> So you ran Point-Stat using these extra 19 masking regions And the
log
> messages from Point-Stat indicate that it's reading data from those
mask
> files. But you see no output data for VX_MASK = land_mask_*.
>
> It's important to note that if Point-Stat found 0 matched pairs for
a
> particular masking region, then nothing will be written to the
output file.
> Typically, I'd recommend looking at the verbosity level 3 log
messages from
> Point-Stat to figure out how many matched pairs were used... and why
they
> were excluded. So if you have the Point-Stat log files, please take
a look
> at that info.
>
> I took a look at the VGTYP masks and see that some of them are
pretty
> sparse... only a handful of points spread out across the grid.
>
> In your Point-Stat config file, I see you're currently using
bilinear
> interpolation... which uses the 4 closest points. If any of those 4
nearby
> points is NOT in the current masking region, then the interpolated
forecast
> value will be set to bad data... so no matched pair.
>
> To test this, please try re-configuring and re-running Point-Stat
using
> both bilinear and nearest neighbor interpolation. Then check to see
if you
> get any land_mask_* output.
>
> //
> // Interpolation methods
> //
> interp = {
> vld_thresh = 1.0;
> type = [
> { method = BILIN; width = 2; },
> { method = NEAREST; width = 1; }
> ];
> }
>
> With nearest neighbor interpolation, I would think that you'd get
some
> land_mask_* output! This highlights the point that masking regions
are
> applied to the gridded forecast data... not the point observations
> themselves. Please let me know what you figure out.
>
> In regards to regrid_data_plane, yes, data must be put onto a common
grid
> to be compared. And yes, you could use regrid_data_plane to do that.
> Alternatively, you can do this regridding directly in the MET
configuration
> files. That avoids the need to run regrid_data_plane at all. But
there are
> pros and cons.
>
> First, let me say how to do this. In the Grid-Stat config file, note
the
> "regrid" section:
>
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/GridStatConfig_default#L31
>
> And here's a description of how to configure those options:
>
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/README#L353
>
> In your case, you could regrid both the forecast and obs data to a
common
> grid by setting:
>
> regrid = {
> to_grid =
> "/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00";
> method = BILIN;
> width = 2;
> vld_thresh = 0.5;
> shape = SQUARE;
> }
> I listed bilinear interpolation, but it's up to you to decide how
they
> should be regridded.
>
> The advantage to regridding directly in the config file is that it's
> convenient and you don't need to write extra data files. The
downside is
> that if you're regridding the same data multiple times, then that's
less
> efficient. For example, let's say you have obs data that you're
verifying
> against 10 different forecast lead times, all valid for that same
time. If
> you regrid in the config file like this, then you're regridding the
same
> obs data 10 times. It would be more efficient to do it once using
> regrid_data_plane and read it's output into Grid-Stat.
>
> So that's up to you to weigh the convenience against the efficiency.
Just
> ask yourself if and how many times you're regridding the same
datasets.
>
> Hope that helps.
>
> Thanks,
> John
>
>
> On Wed, Jul 29, 2020 at 5:12 PM John Halley Gotway <johnhg at ucar.edu>
> wrote:
>
> > Ed,
> >
> > Sorry for the delay Ed. I had hoped to get to this today but ran
out of
> > time. I'll take a look tomorrow. Just wanted to let you know that
I
> haven't
> > forgotten about it.
> >
> > Thanks,
> > John
> >
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Fri Jul 31 11:26:15 2020
Ed,
As you figured out, when setting poly =
"/path/to/netcdf/output/of/gen_vx_mask", the VX_MASK name is the name
of
the variable from that file. I'd recommend updating your Mask_Maker.sh
script to pass the "-name" command line argument to the gen_vx_mask
tool.
That explicitly defines the output variable name you'd like written to
the
output, rather than using the default "data_mask" name:
* "-name string" specifies the output variable name for the mask
(optional).*
I'd like to take a closer look at the log file from which you sent
excerpts. I hunted around on WCOSS a bit but couldn't find it. Can you
please send me the path to it?
Thanks,
John
On Fri, Jul 31, 2020 at 9:38 AM Edward Strobach - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
>
> Hi John,
>
> Thanks for the suggestions to improve efficiency. I shall look into
that
> once I can get the immediate issue squared away.
>
> I agree with you that many of the masked regions that have been
created
> will not have nearby observations that can be used for validation.
> However, some of the masked regions are quite large. Look at the
attached
> plot for example, which I believe was from the land_mask_11.nc file.
You
> can see that there is a considerable amount of coverage over CONUS
from
> this particular masked region. I would have expected at least
something
> based on the coverage of both this region and obs.
>
> I have gone ahead and added the nearest neighbor interpolation. I
had
> intended to do that anyways since I thought it would be more
appropriate
> for this kind of field, especially since the ozone and pm fields may
not
> always be continuous, and thus more local in nature.
> As recommended, I changed the verbosity for point stat to 3 in order
to
> examine matched pairs to see if any of the masks were selected.
>
> It does appear that all of these files are being examined to see if
there
> are matched pairs. I had to take a look carefully because I
originally
> assumed that I would be looking for land_mask_XX when searching for
matched
> pairs. My thinking was that the masks would be named based on the
name of
> the file. It turns out that it uses the name within the file. The
poly
> files have the regions listed at the top while the name in the
netcdf files
> is data_mask for all files. That may be a problem later on since
I'll
> ultimately want to distinguish these regions based on a clearly
written
> name that distinguishes regions. As you can see all masked regions
are
> being processed, but despite including nearest neighbor
interpolation, I
> still get 0 matched pairs.
>
> DEBUG 2: Reading data for TMP/Z2.
> DEBUG 3: Use the matching forecast and observation grids.
> DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 468 Ny:
288
> Lat_LL: 21.017 Lon_LL: 123.282 Lon_orient: 97.000 Alpha: 1037.975
Cone:
> 0.630 Bx: 233.6421 By: 785.2276
> DEBUG 2: Processing masking regions.
> DEBUG 3: Processing grid mask: G236
> DEBUG 3: Processing poly mask: MET_BASE/poly/CONUS.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/NEC.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/SEC.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/NWC.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/SWC.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/NMT.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/SMT.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/GRB.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/SWD.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/NPL.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/SPL.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/MDW.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/LMV.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/GMC.poly
> DEBUG 3: Processing poly mask: MET_BASE/poly/APL.poly
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_0.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_1.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_2.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_3.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_4.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_5.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_6.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_7.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_8.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_9.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_10.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_11.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_12.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_13.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_14.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_15.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_16.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_17.nc
> DEBUG 3: Processing poly mask:
>
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> land_mask_18.nc
> DEBUG 2: Processing geography data.
>
> For example, the GMC region has 496
>
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ONLYSF, over
> region GMC, for interpolation method BILIN(4), using 496 matched
pairs.
> DEBUG 3: Number of matched pairs = 496
> DEBUG 3: Observations processed = 41207
> DEBUG 3: Rejected: station id = 0
> DEBUG 3: Rejected: obs type = 35085
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 397
> DEBUG 3: Rejected: topography = 0
> DEBUG 3: Rejected: level mismatch = 0
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 5229
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: bad climo mean = 0
> DEBUG 3: Rejected: bad climo stdev = 0
> DEBUG 3: Rejected: duplicates = 0
> DEBUG 2: Computing Categorical Statistics.
> DEBUG 2: Computing Scalar Partial Sums and Continuous Statistics.
>
> While, this example of data_mask (as well as the 18 others) have 0
matched
> pairs.
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ONLYSF, over
> region data_mask, for interpolation method BILIN(4), using 0 matched
pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 41207
> DEBUG 3: Rejected: station id = 0
> DEBUG 3: Rejected: obs type = 35085
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 397
> DEBUG 3: Rejected: topography = 0
> DEBUG 3: Rejected: level mismatch = 0
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 5725
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: bad climo mean = 0
> DEBUG 3: Rejected: bad climo stdev = 0
> DEBUG 3: Rejected: duplicates = 0
>
> So, for ONLYSF, there are written out statements for 2-m temperature
in
> accordance with the two interpolation options listed. Again, I'm a
bit
> surprised that 0 matched pairs were found for all regions,
especially since
> some regions, like the one attached below, have a decent amount of
> coverage.
>
> As for regridding data, I think I want to stick with running
> RegridDataPlane. In the pointstat configure files, the ozone and pm
data
> being generated are stored on the "FULL" cmaq grid, whereas the
meteorology
> used to drive CMAQ is stored on a different grid. in the two
pointstat
> files I use, I see
>
> mask = {
> grid = [ "FULL" ];
> poly = [ "MET_BASE/poly/CONUS.poly",
"MET_BASE/poly/EAST.poly",
> "MET_BASE/poly/WEST.poly",
> "MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
> "MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
> "MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
> "MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
> "MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
> "MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
> "MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
> "MET_BASE/poly/APL.poly" ];
> sid = [];
> }
>
> with grid set to FULL
>
> and with the meteorology I see
>
> mask = {
> // grid = [ "G236", "G245", "G246" ];
> poly = [ "MET_BASE/poly/CONUS.poly",
> "MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
> "MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
> "MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
> "MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
> "MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
> "MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
> "MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
> "MET_BASE/poly/APL.poly", "${MET_PLUS}/polydata/land_mask/${DATE}/
> land_mask_0.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_1.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_2.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_3.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_4.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_5.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_6.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_7.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_8.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_9.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_10.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_11.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_12.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_13.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_14.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_15.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_16.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_17.nc",
> "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_18.nc" ];
> grid = ${POINT_STAT_GRID};
> // poly = ${POINT_STAT_POLY};
> sid = [];
> }
>
> which specifies 3 separate grids. That confuses me a bit, to be
honest, so
> it's hard for me to visualize how to configure regrid for remapping
the
> ozone and pm being generated to the same grid as the meteorology.
I'll
> ultimately want to remap to this grid so I can use the land mask
files for
> pm and ozone as well. however, somehow, based on recent
developments,
> there doesn't seem to be any matched pairs. RegridDataPlane seems
to take
> the obs and regrid it to match that of the forecast grid.
>
> I think in my case I would set the following in RegridDataPlane:
>
> OBS_REGRID_DATA_PLANE_RUN = False
> FCST_REGRID_DATA_PLANE_RUN = True
>
> I would list all fields and levels that I want regridded - pm and
> ozone at the surface in this case - and specify a file
> that contains the information about what grid I want to regrid to.
> In the example online, there is this:
>
>
>
REGRID_DATA_PLANE_VERIF_GRID={INPUT_BASE}/met_test/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>
> I'm not exactly sure what's in that file, but I'm trying to see if I
> could use an arbitrary file from the meteorology output:
> aqm.t00z.nmm00.tm00
>
> I'm wondering if met would know to take the lat/lons from this file
> and convert the ozone and pm data to grid specified by the
>
> lat lons in that file. If so, then I'm good. An alternative is to
> get my federal oversight manager to create an action item for
>
> item to regrid the land mask data onto the grid that the ozone and
pm is
> on.
>
>
>
>
>
>
> On Thu, Jul 30, 2020 at 6:57 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Ed,
> >
> > I see that you were able to make some progress. That's interesting
that
> > you're regenerating them each day. This sounds similar to what
Logan
> Dawson
> > from NOAA/EMC is doing in the verifying daily precip warning
areas. He
> runs
> > gen_vx_mask each day to define masking regions from shapefiles
(from WPC
> I
> > think?). So the regions change each day. I'm glad to hear that
logic is
> > working.
> >
> > Thanks for sending your mask config file entries. I have a couple
of
> > suggestions.
> >
> > (1) Since those CONUS and sub-region polylines remain fixed, it'd
be more
> > efficient to run them through gen_vx_mask, generate NetCDF output
for
> your
> > domain, and list the NetCDF mask files there instead. Using the
.poly
> files
> > does work, but every time you run, Point-Stat wastes time figuring
out
> > which points are inside/outside each region. For a coarse grid,
the
> > difference may not be noticeable, but for something like the HRRR
grid,
> it
> > could be significant.
> >
> > The downside is that if you change verification domains, you
should
> > regenerate those NetCDF mask files.
> >
> > (2) Conversely, if generating those 19 extra NetCDF mask files
each day
> for
> > the VGTYP data is too much overhead, you could do this simple data
> masking
> > directly in the config file. For example, let's say you've set an
> > environment variable FCST_FILE = path to your current input data
file.
> You
> > could define:
> >
> > mask = {
> > // grid = [ "G236", "G245", "G246" ];
> > poly = [ ...
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq0",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq1",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq2",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq3",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq4",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq5",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq6",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq7",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq8",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq9",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq10",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq11",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq12",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq13",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq14",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq15",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq16",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq17",
> > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq18"
> > ];
> >
> > That'll define your 19 masks by applying the threshold we've
listed for
> > each. The downside is that you'll have no control over how the
VX_MASK is
> > named. You'll get some unique string, but you won't be able to
modify it.
> >
> > I'm not sure if this would be any faster, but then you wouldn't
need to
> > generate all those extra NetCDF files each day.
> >
> > But getting on the specific question you asked...
> >
> > So you ran Point-Stat using these extra 19 masking regions And the
log
> > messages from Point-Stat indicate that it's reading data from
those mask
> > files. But you see no output data for VX_MASK = land_mask_*.
> >
> > It's important to note that if Point-Stat found 0 matched pairs
for a
> > particular masking region, then nothing will be written to the
output
> file.
> > Typically, I'd recommend looking at the verbosity level 3 log
messages
> from
> > Point-Stat to figure out how many matched pairs were used... and
why they
> > were excluded. So if you have the Point-Stat log files, please
take a
> look
> > at that info.
> >
> > I took a look at the VGTYP masks and see that some of them are
pretty
> > sparse... only a handful of points spread out across the grid.
> >
> > In your Point-Stat config file, I see you're currently using
bilinear
> > interpolation... which uses the 4 closest points. If any of those
4
> nearby
> > points is NOT in the current masking region, then the interpolated
> forecast
> > value will be set to bad data... so no matched pair.
> >
> > To test this, please try re-configuring and re-running Point-Stat
using
> > both bilinear and nearest neighbor interpolation. Then check to
see if
> you
> > get any land_mask_* output.
> >
> > //
> > // Interpolation methods
> > //
> > interp = {
> > vld_thresh = 1.0;
> > type = [
> > { method = BILIN; width = 2; },
> > { method = NEAREST; width = 1; }
> > ];
> > }
> >
> > With nearest neighbor interpolation, I would think that you'd get
some
> > land_mask_* output! This highlights the point that masking regions
are
> > applied to the gridded forecast data... not the point observations
> > themselves. Please let me know what you figure out.
> >
> > In regards to regrid_data_plane, yes, data must be put onto a
common grid
> > to be compared. And yes, you could use regrid_data_plane to do
that.
> > Alternatively, you can do this regridding directly in the MET
> configuration
> > files. That avoids the need to run regrid_data_plane at all. But
there
> are
> > pros and cons.
> >
> > First, let me say how to do this. In the Grid-Stat config file,
note the
> > "regrid" section:
> >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/GridStatConfig_default#L31
> >
> > And here's a description of how to configure those options:
> >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/README#L353
> >
> > In your case, you could regrid both the forecast and obs data to a
common
> > grid by setting:
> >
> > regrid = {
> > to_grid =
> > "/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00";
> > method = BILIN;
> > width = 2;
> > vld_thresh = 0.5;
> > shape = SQUARE;
> > }
> > I listed bilinear interpolation, but it's up to you to decide how
they
> > should be regridded.
> >
> > The advantage to regridding directly in the config file is that
it's
> > convenient and you don't need to write extra data files. The
downside is
> > that if you're regridding the same data multiple times, then
that's less
> > efficient. For example, let's say you have obs data that you're
verifying
> > against 10 different forecast lead times, all valid for that same
time.
> If
> > you regrid in the config file like this, then you're regridding
the same
> > obs data 10 times. It would be more efficient to do it once using
> > regrid_data_plane and read it's output into Grid-Stat.
> >
> > So that's up to you to weigh the convenience against the
efficiency. Just
> > ask yourself if and how many times you're regridding the same
datasets.
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
> >
> > On Wed, Jul 29, 2020 at 5:12 PM John Halley Gotway
<johnhg at ucar.edu>
> > wrote:
> >
> > > Ed,
> > >
> > > Sorry for the delay Ed. I had hoped to get to this today but ran
out of
> > > time. I'll take a look tomorrow. Just wanted to let you know
that I
> > haven't
> > > forgotten about it.
> > >
> > > Thanks,
> > > John
> > >
> >
> >
>
> --
> Edward Strobach
> EMC/NCEP/NWS/
> IMSG Contractor
> Cubicle#: 2029
> 301-683-3717
>
>
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Edward Strobach - NOAA Affiliate
Time: Fri Jul 31 12:48:56 2020
Hi John, I just realized that I forgot to include the "-name" part.
Thanks! BTW, the regrid issue is more or less resolved, so I'm good
there
at least.
I have continued to study this file
(/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_aq/CMAQ_Meteorology/logs/master_metplus.log.20200731142200),
which represents the latest attempt. Looking for instances of where
data_mask and land_mask have more or less led to the same conclusion
drawn
from my previous email. However, you might find something that I
didn't.
I think my next test will be to group all the points over land and
neglect
water (i.e. ne0). I should have matched pairs then. If not, then I
know
something is wrong with my set-up. I think that sounds like a logical
next
step. I may do that shortly but have something else I need to square
away
first.
On Fri, Jul 31, 2020 at 1:26 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Ed,
>
> As you figured out, when setting poly =
> "/path/to/netcdf/output/of/gen_vx_mask", the VX_MASK name is the
name of
> the variable from that file. I'd recommend updating your
Mask_Maker.sh
> script to pass the "-name" command line argument to the gen_vx_mask
tool.
> That explicitly defines the output variable name you'd like written
to the
> output, rather than using the default "data_mask" name:
> * "-name string" specifies the output variable name for the mask
> (optional).*
>
> I'd like to take a closer look at the log file from which you sent
> excerpts. I hunted around on WCOSS a bit but couldn't find it. Can
you
> please send me the path to it?
>
> Thanks,
> John
>
>
> On Fri, Jul 31, 2020 at 9:38 AM Edward Strobach - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
> >
> > Hi John,
> >
> > Thanks for the suggestions to improve efficiency. I shall look
into that
> > once I can get the immediate issue squared away.
> >
> > I agree with you that many of the masked regions that have been
created
> > will not have nearby observations that can be used for validation.
> > However, some of the masked regions are quite large. Look at the
> attached
> > plot for example, which I believe was from the land_mask_11.nc
file.
> You
> > can see that there is a considerable amount of coverage over CONUS
from
> > this particular masked region. I would have expected at least
something
> > based on the coverage of both this region and obs.
> >
> > I have gone ahead and added the nearest neighbor interpolation. I
had
> > intended to do that anyways since I thought it would be more
appropriate
> > for this kind of field, especially since the ozone and pm fields
may not
> > always be continuous, and thus more local in nature.
> > As recommended, I changed the verbosity for point stat to 3 in
order to
> > examine matched pairs to see if any of the masks were selected.
> >
> > It does appear that all of these files are being examined to see
if there
> > are matched pairs. I had to take a look carefully because I
originally
> > assumed that I would be looking for land_mask_XX when searching
for
> matched
> > pairs. My thinking was that the masks would be named based on the
name
> of
> > the file. It turns out that it uses the name within the file. The
poly
> > files have the regions listed at the top while the name in the
netcdf
> files
> > is data_mask for all files. That may be a problem later on since
I'll
> > ultimately want to distinguish these regions based on a clearly
written
> > name that distinguishes regions. As you can see all masked
regions are
> > being processed, but despite including nearest neighbor
interpolation, I
> > still get 0 matched pairs.
> >
> > DEBUG 2: Reading data for TMP/Z2.
> > DEBUG 3: Use the matching forecast and observation grids.
> > DEBUG 3: Grid Definition: Projection: Lambert Conformal Nx: 468
Ny: 288
> > Lat_LL: 21.017 Lon_LL: 123.282 Lon_orient: 97.000 Alpha: 1037.975
Cone:
> > 0.630 Bx: 233.6421 By: 785.2276
> > DEBUG 2: Processing masking regions.
> > DEBUG 3: Processing grid mask: G236
> > DEBUG 3: Processing poly mask: MET_BASE/poly/CONUS.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/NEC.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/SEC.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/NWC.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/SWC.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/NMT.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/SMT.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/GRB.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/SWD.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/NPL.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/SPL.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/MDW.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/LMV.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/GMC.poly
> > DEBUG 3: Processing poly mask: MET_BASE/poly/APL.poly
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_0.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_1.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_2.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_3.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_4.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_5.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_6.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_7.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_8.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_9.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_10.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_11.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_12.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_13.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_14.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_15.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_16.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_17.nc
> > DEBUG 3: Processing poly mask:
> >
> >
>
/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/polydata/land_mask/20200728/
> > land_mask_18.nc
> > DEBUG 2: Processing geography data.
> >
> > For example, the GMC region has 496
> >
> > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ONLYSF,
> over
> > region GMC, for interpolation method BILIN(4), using 496 matched
pairs.
> > DEBUG 3: Number of matched pairs = 496
> > DEBUG 3: Observations processed = 41207
> > DEBUG 3: Rejected: station id = 0
> > DEBUG 3: Rejected: obs type = 35085
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 0
> > DEBUG 3: Rejected: off the grid = 397
> > DEBUG 3: Rejected: topography = 0
> > DEBUG 3: Rejected: level mismatch = 0
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 0
> > DEBUG 3: Rejected: masking region = 5229
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: bad climo mean = 0
> > DEBUG 3: Rejected: bad climo stdev = 0
> > DEBUG 3: Rejected: duplicates = 0
> > DEBUG 2: Computing Categorical Statistics.
> > DEBUG 2: Computing Scalar Partial Sums and Continuous Statistics.
> >
> > While, this example of data_mask (as well as the 18 others) have 0
> matched
> > pairs.
> > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
ONLYSF,
> over
> > region data_mask, for interpolation method BILIN(4), using 0
matched
> pairs.
> > DEBUG 3: Number of matched pairs = 0
> > DEBUG 3: Observations processed = 41207
> > DEBUG 3: Rejected: station id = 0
> > DEBUG 3: Rejected: obs type = 35085
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 0
> > DEBUG 3: Rejected: off the grid = 397
> > DEBUG 3: Rejected: topography = 0
> > DEBUG 3: Rejected: level mismatch = 0
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 0
> > DEBUG 3: Rejected: masking region = 5725
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: bad climo mean = 0
> > DEBUG 3: Rejected: bad climo stdev = 0
> > DEBUG 3: Rejected: duplicates = 0
> >
> > So, for ONLYSF, there are written out statements for 2-m
temperature in
> > accordance with the two interpolation options listed. Again, I'm
a bit
> > surprised that 0 matched pairs were found for all regions,
especially
> since
> > some regions, like the one attached below, have a decent amount of
> > coverage.
> >
> > As for regridding data, I think I want to stick with running
> > RegridDataPlane. In the pointstat configure files, the ozone and
pm data
> > being generated are stored on the "FULL" cmaq grid, whereas the
> meteorology
> > used to drive CMAQ is stored on a different grid. in the two
pointstat
> > files I use, I see
> >
> > mask = {
> > grid = [ "FULL" ];
> > poly = [ "MET_BASE/poly/CONUS.poly",
"MET_BASE/poly/EAST.poly",
> > "MET_BASE/poly/WEST.poly",
> > "MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
> > "MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
> > "MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
> > "MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
> > "MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
> > "MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
> > "MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
> > "MET_BASE/poly/APL.poly" ];
> > sid = [];
> > }
> >
> > with grid set to FULL
> >
> > and with the meteorology I see
> >
> > mask = {
> > // grid = [ "G236", "G245", "G246" ];
> > poly = [ "MET_BASE/poly/CONUS.poly",
> > "MET_BASE/poly/NEC.poly","MET_BASE/poly/SEC.poly",
> > "MET_BASE/poly/NWC.poly", "MET_BASE/poly/SWC.poly",
> > "MET_BASE/poly/NMT.poly", "MET_BASE/poly/SMT.poly",
> > "MET_BASE/poly/GRB.poly", "MET_BASE/poly/SWD.poly",
> > "MET_BASE/poly/NPL.poly", "MET_BASE/poly/SPL.poly",
> > "MET_BASE/poly/MDW.poly", "MET_BASE/poly/MDW.poly",
> > "MET_BASE/poly/LMV.poly", "MET_BASE/poly/GMC.poly",
> > "MET_BASE/poly/APL.poly", "${MET_PLUS}/polydata/land_mask/${DATE}/
> > land_mask_0.nc",
"${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_1.nc
> ",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_2.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_3.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_4.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_5.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_6.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_7.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_8.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_9.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_10.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_11.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_12.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_13.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_14.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_15.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_16.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_17.nc",
> > "${MET_PLUS}/polydata/land_mask/${DATE}/land_mask_18.nc" ];
> > grid = ${POINT_STAT_GRID};
> > // poly = ${POINT_STAT_POLY};
> > sid = [];
> > }
> >
> > which specifies 3 separate grids. That confuses me a bit, to be
honest,
> so
> > it's hard for me to visualize how to configure regrid for
remapping the
> > ozone and pm being generated to the same grid as the meteorology.
I'll
> > ultimately want to remap to this grid so I can use the land mask
files
> for
> > pm and ozone as well. however, somehow, based on recent
developments,
> > there doesn't seem to be any matched pairs. RegridDataPlane seems
to
> take
> > the obs and regrid it to match that of the forecast grid.
> >
> > I think in my case I would set the following in RegridDataPlane:
> >
> > OBS_REGRID_DATA_PLANE_RUN = False
> > FCST_REGRID_DATA_PLANE_RUN = True
> >
> > I would list all fields and levels that I want regridded - pm and
> > ozone at the surface in this case - and specify a file
> > that contains the information about what grid I want to regrid
to.
> > In the example online, there is this:
> >
> >
> >
>
REGRID_DATA_PLANE_VERIF_GRID={INPUT_BASE}/met_test/data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
> >
> > I'm not exactly sure what's in that file, but I'm trying to see if
I
> > could use an arbitrary file from the meteorology output:
> > aqm.t00z.nmm00.tm00
> >
> > I'm wondering if met would know to take the lat/lons from this
file
> > and convert the ozone and pm data to grid specified by the
> >
> > lat lons in that file. If so, then I'm good. An alternative is
to
> > get my federal oversight manager to create an action item for
> >
> > item to regrid the land mask data onto the grid that the ozone and
pm is
> > on.
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 30, 2020 at 6:57 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Ed,
> > >
> > > I see that you were able to make some progress. That's
interesting that
> > > you're regenerating them each day. This sounds similar to what
Logan
> > Dawson
> > > from NOAA/EMC is doing in the verifying daily precip warning
areas. He
> > runs
> > > gen_vx_mask each day to define masking regions from shapefiles
(from
> WPC
> > I
> > > think?). So the regions change each day. I'm glad to hear that
logic is
> > > working.
> > >
> > > Thanks for sending your mask config file entries. I have a
couple of
> > > suggestions.
> > >
> > > (1) Since those CONUS and sub-region polylines remain fixed,
it'd be
> more
> > > efficient to run them through gen_vx_mask, generate NetCDF
output for
> > your
> > > domain, and list the NetCDF mask files there instead. Using the
.poly
> > files
> > > does work, but every time you run, Point-Stat wastes time
figuring out
> > > which points are inside/outside each region. For a coarse grid,
the
> > > difference may not be noticeable, but for something like the
HRRR grid,
> > it
> > > could be significant.
> > >
> > > The downside is that if you change verification domains, you
should
> > > regenerate those NetCDF mask files.
> > >
> > > (2) Conversely, if generating those 19 extra NetCDF mask files
each day
> > for
> > > the VGTYP data is too much overhead, you could do this simple
data
> > masking
> > > directly in the config file. For example, let's say you've set
an
> > > environment variable FCST_FILE = path to your current input data
file.
> > You
> > > could define:
> > >
> > > mask = {
> > > // grid = [ "G236", "G245", "G246" ];
> > > poly = [ ...
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq0",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq1",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq2",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq3",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq4",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq5",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq6",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq7",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq8",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq9",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq10",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq11",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq12",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq13",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq14",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq15",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq16",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq17",
> > > "${FCST_FILE} { name = \"VGTYP\"; level = \"Z0\"; } eq18"
> > > ];
> > >
> > > That'll define your 19 masks by applying the threshold we've
listed for
> > > each. The downside is that you'll have no control over how the
VX_MASK
> is
> > > named. You'll get some unique string, but you won't be able to
modify
> it.
> > >
> > > I'm not sure if this would be any faster, but then you wouldn't
need to
> > > generate all those extra NetCDF files each day.
> > >
> > > But getting on the specific question you asked...
> > >
> > > So you ran Point-Stat using these extra 19 masking regions And
the log
> > > messages from Point-Stat indicate that it's reading data from
those
> mask
> > > files. But you see no output data for VX_MASK = land_mask_*.
> > >
> > > It's important to note that if Point-Stat found 0 matched pairs
for a
> > > particular masking region, then nothing will be written to the
output
> > file.
> > > Typically, I'd recommend looking at the verbosity level 3 log
messages
> > from
> > > Point-Stat to figure out how many matched pairs were used... and
why
> they
> > > were excluded. So if you have the Point-Stat log files, please
take a
> > look
> > > at that info.
> > >
> > > I took a look at the VGTYP masks and see that some of them are
pretty
> > > sparse... only a handful of points spread out across the grid.
> > >
> > > In your Point-Stat config file, I see you're currently using
bilinear
> > > interpolation... which uses the 4 closest points. If any of
those 4
> > nearby
> > > points is NOT in the current masking region, then the
interpolated
> > forecast
> > > value will be set to bad data... so no matched pair.
> > >
> > > To test this, please try re-configuring and re-running Point-
Stat using
> > > both bilinear and nearest neighbor interpolation. Then check to
see if
> > you
> > > get any land_mask_* output.
> > >
> > > //
> > > // Interpolation methods
> > > //
> > > interp = {
> > > vld_thresh = 1.0;
> > > type = [
> > > { method = BILIN; width = 2; },
> > > { method = NEAREST; width = 1; }
> > > ];
> > > }
> > >
> > > With nearest neighbor interpolation, I would think that you'd
get some
> > > land_mask_* output! This highlights the point that masking
regions are
> > > applied to the gridded forecast data... not the point
observations
> > > themselves. Please let me know what you figure out.
> > >
> > > In regards to regrid_data_plane, yes, data must be put onto a
common
> grid
> > > to be compared. And yes, you could use regrid_data_plane to do
that.
> > > Alternatively, you can do this regridding directly in the MET
> > configuration
> > > files. That avoids the need to run regrid_data_plane at all. But
there
> > are
> > > pros and cons.
> > >
> > > First, let me say how to do this. In the Grid-Stat config file,
note
> the
> > > "regrid" section:
> > >
> > >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/GridStatConfig_default#L31
> > >
> > > And here's a description of how to configure those options:
> > >
> > >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/data/config/README#L353
> > >
> > > In your case, you could regrid both the forecast and obs data to
a
> common
> > > grid by setting:
> > >
> > > regrid = {
> > > to_grid =
> > >
"/gpfs/hps/nco/ops/com/aqm/prod/aqm.20200725/aqm.t06z.nmm15.tm00";
> > > method = BILIN;
> > > width = 2;
> > > vld_thresh = 0.5;
> > > shape = SQUARE;
> > > }
> > > I listed bilinear interpolation, but it's up to you to decide
how they
> > > should be regridded.
> > >
> > > The advantage to regridding directly in the config file is that
it's
> > > convenient and you don't need to write extra data files. The
downside
> is
> > > that if you're regridding the same data multiple times, then
that's
> less
> > > efficient. For example, let's say you have obs data that you're
> verifying
> > > against 10 different forecast lead times, all valid for that
same time.
> > If
> > > you regrid in the config file like this, then you're regridding
the
> same
> > > obs data 10 times. It would be more efficient to do it once
using
> > > regrid_data_plane and read it's output into Grid-Stat.
> > >
> > > So that's up to you to weigh the convenience against the
efficiency.
> Just
> > > ask yourself if and how many times you're regridding the same
datasets.
> > >
> > > Hope that helps.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Wed, Jul 29, 2020 at 5:12 PM John Halley Gotway
<johnhg at ucar.edu>
> > > wrote:
> > >
> > > > Ed,
> > > >
> > > > Sorry for the delay Ed. I had hoped to get to this today but
ran out
> of
> > > > time. I'll take a look tomorrow. Just wanted to let you know
that I
> > > haven't
> > > > forgotten about it.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > >
> > >
> >
> > --
> > Edward Strobach
> > EMC/NCEP/NWS/
> > IMSG Contractor
> > Cubicle#: 2029
> > 301-683-3717
> >
> >
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Fri Jul 31 17:40:16 2020
Ed,
I downloaded that log file (master_metplus.log.20200731142200) and was
surprised to see that it's 79mb!
OK, I think I know why you're getting 0 matched pairs. Since you're
masks
are all named "data_mask", they're over-writing each other. So that
means
that whatever mask is last (i.e. data_mask for VGTYP == 17) is the
only one
that's actually being applied.
So if you regenerate your masks using the -name command line option to
make
them unique, then you should get matched pairs for some of them.
This is the line of code in Point-Stat where this happens:
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
But why would we design it in this way? The user has the flexibility
to
define different masking regions for different variables. But if we
were to
store all of them in memory for all variables, then it'd be very, very
slow
and inefficient. So the code processes all of the masks for each
variable,
but only stores in memory the unique ones.
Ideally we'd enhance Point-Stat to print a warning or error message
for
non-unique masking region names, but it isn't immediately obvious to
me
where that logic should go. But I can add a GitHub issue to figure
that out.
Please let me know if fixing the mask names fixes the matched pair
problem.
John
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Fri Jul 31 17:49:34 2020
Ed,
FYI, here's the GitHub issue I wrote up to check for this situation
and
error out with a useful error message:
https://github.com/NCAR/MET/issues/1439
Have a great weekend.
John
On Fri, Jul 31, 2020 at 5:40 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Ed,
>
> I downloaded that log file (master_metplus.log.20200731142200) and
was
> surprised to see that it's 79mb!
>
> OK, I think I know why you're getting 0 matched pairs. Since you're
masks
> are all named "data_mask", they're over-writing each other. So that
means
> that whatever mask is last (i.e. data_mask for VGTYP == 17) is the
only one
> that's actually being applied.
>
> So if you regenerate your masks using the -name command line option
to
> make them unique, then you should get matched pairs for some of
them.
>
> This is the line of code in Point-Stat where this happens:
>
>
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
>
> But why would we design it in this way? The user has the flexibility
to
> define different masking regions for different variables. But if we
were to
> store all of them in memory for all variables, then it'd be very,
very slow
> and inefficient. So the code processes all of the masks for each
variable,
> but only stores in memory the unique ones.
>
> Ideally we'd enhance Point-Stat to print a warning or error message
for
> non-unique masking region names, but it isn't immediately obvious to
me
> where that logic should go. But I can add a GitHub issue to figure
that out.
>
> Please let me know if fixing the mask names fixes the matched pair
problem.
>
> John
>
>
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Edward Strobach - NOAA Affiliate
Time: Mon Aug 03 11:16:30 2020
Hi John,
I haven't pursued your suggestion yet, but will do so right now and
inform
you of the result as requested. I agree with your assessment about
data_mask being overwritten owing to the non-uniqueness of the name;
however, I would still have thought that matched pairs for some of the
land
mask files would have been realized even though only land_mask 18 was
written out. I say this because the log indicates that 19 operations
(0
through 18) were performed according to the land_mask_XX.nc dataset.
That
means that all files were processed. However, all 19 files that were
processed indicated 0 matched pairs. I know you reiterate this reason
in
the github issue you wrote, but it may be due to my lack of
understanding.
I'll add a uniqueness indicator and see what happens. Thanks again
for
your help and explanations.
On Fri, Jul 31, 2020 at 7:49 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Ed,
>
> FYI, here's the GitHub issue I wrote up to check for this situation
and
> error out with a useful error message:
> https://github.com/NCAR/MET/issues/1439
>
> Have a great weekend.
>
> John
>
> On Fri, Jul 31, 2020 at 5:40 PM John Halley Gotway <johnhg at ucar.edu>
> wrote:
>
> > Ed,
> >
> > I downloaded that log file (master_metplus.log.20200731142200) and
was
> > surprised to see that it's 79mb!
> >
> > OK, I think I know why you're getting 0 matched pairs. Since
you're masks
> > are all named "data_mask", they're over-writing each other. So
that means
> > that whatever mask is last (i.e. data_mask for VGTYP == 17) is the
only
> one
> > that's actually being applied.
> >
> > So if you regenerate your masks using the -name command line
option to
> > make them unique, then you should get matched pairs for some of
them.
> >
> > This is the line of code in Point-Stat where this happens:
> >
> >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
> >
> > But why would we design it in this way? The user has the
flexibility to
> > define different masking regions for different variables. But if
we were
> to
> > store all of them in memory for all variables, then it'd be very,
very
> slow
> > and inefficient. So the code processes all of the masks for each
> variable,
> > but only stores in memory the unique ones.
> >
> > Ideally we'd enhance Point-Stat to print a warning or error
message for
> > non-unique masking region names, but it isn't immediately obvious
to me
> > where that logic should go. But I can add a GitHub issue to figure
that
> out.
> >
> > Please let me know if fixing the mask names fixes the matched pair
> problem.
> >
> > John
> >
> >
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Mon Aug 03 11:22:10 2020
Ed,
Sounds good. I'll keep my fingers crossed that you get sane output
with
unique mask names.
FYI, one easy thing to test with your existing data is reconfiguring
Point-Stat to only use a single input mask file. I'd choose whichever
has
the largest number of mask points. So instead of listing 19 data_mask
files, only list one. And I'd guess that you would indeed get output
for
that.
But switching to using unique masking variable names is the better
longterm
solution.
John
On Mon, Aug 3, 2020 at 11:16 AM Edward Strobach - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
>
> Hi John,
>
> I haven't pursued your suggestion yet, but will do so right now and
inform
> you of the result as requested. I agree with your assessment about
> data_mask being overwritten owing to the non-uniqueness of the name;
> however, I would still have thought that matched pairs for some of
the land
> mask files would have been realized even though only land_mask 18
was
> written out. I say this because the log indicates that 19
operations (0
> through 18) were performed according to the land_mask_XX.nc dataset.
That
> means that all files were processed. However, all 19 files that
were
> processed indicated 0 matched pairs. I know you reiterate this
reason in
> the github issue you wrote, but it may be due to my lack of
understanding.
>
> I'll add a uniqueness indicator and see what happens. Thanks again
for
> your help and explanations.
>
> On Fri, Jul 31, 2020 at 7:49 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Ed,
> >
> > FYI, here's the GitHub issue I wrote up to check for this
situation and
> > error out with a useful error message:
> > https://github.com/NCAR/MET/issues/1439
> >
> > Have a great weekend.
> >
> > John
> >
> > On Fri, Jul 31, 2020 at 5:40 PM John Halley Gotway
<johnhg at ucar.edu>
> > wrote:
> >
> > > Ed,
> > >
> > > I downloaded that log file (master_metplus.log.20200731142200)
and was
> > > surprised to see that it's 79mb!
> > >
> > > OK, I think I know why you're getting 0 matched pairs. Since
you're
> masks
> > > are all named "data_mask", they're over-writing each other. So
that
> means
> > > that whatever mask is last (i.e. data_mask for VGTYP == 17) is
the only
> > one
> > > that's actually being applied.
> > >
> > > So if you regenerate your masks using the -name command line
option to
> > > make them unique, then you should get matched pairs for some of
them.
> > >
> > > This is the line of code in Point-Stat where this happens:
> > >
> > >
> > >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
> > >
> > > But why would we design it in this way? The user has the
flexibility to
> > > define different masking regions for different variables. But if
we
> were
> > to
> > > store all of them in memory for all variables, then it'd be
very, very
> > slow
> > > and inefficient. So the code processes all of the masks for each
> > variable,
> > > but only stores in memory the unique ones.
> > >
> > > Ideally we'd enhance Point-Stat to print a warning or error
message for
> > > non-unique masking region names, but it isn't immediately
obvious to me
> > > where that logic should go. But I can add a GitHub issue to
figure that
> > out.
> > >
> > > Please let me know if fixing the mask names fixes the matched
pair
> > problem.
> > >
> > > John
> > >
> > >
> >
> >
>
> --
> Edward Strobach
> EMC/NCEP/NWS/
> IMSG Contractor
> Cubicle#: 2029
> 301-683-3717
>
>
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: Edward Strobach - NOAA Affiliate
Time: Mon Aug 03 11:37:52 2020
Good news John! Your suggestion worked and I have an abundance of
matched
pairs after creating a unique name when running gen_vx_mask. Although
it
took me some time to orient myself around what was being done, I think
I
have relatively good grasp now and should be able to move forward with
all
kinds of masking approaches. I really appreciate you taking the time
to
help and explain things. I've learned a lot.
On Mon, Aug 3, 2020 at 1:22 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Ed,
>
> Sounds good. I'll keep my fingers crossed that you get sane output
with
> unique mask names.
>
> FYI, one easy thing to test with your existing data is reconfiguring
> Point-Stat to only use a single input mask file. I'd choose
whichever has
> the largest number of mask points. So instead of listing 19
data_mask
> files, only list one. And I'd guess that you would indeed get output
for
> that.
>
> But switching to using unique masking variable names is the better
longterm
> solution.
>
> John
>
> On Mon, Aug 3, 2020 at 11:16 AM Edward Strobach - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
> >
> > Hi John,
> >
> > I haven't pursued your suggestion yet, but will do so right now
and
> inform
> > you of the result as requested. I agree with your assessment
about
> > data_mask being overwritten owing to the non-uniqueness of the
name;
> > however, I would still have thought that matched pairs for some of
the
> land
> > mask files would have been realized even though only land_mask 18
was
> > written out. I say this because the log indicates that 19
operations (0
> > through 18) were performed according to the land_mask_XX.nc
dataset.
> That
> > means that all files were processed. However, all 19 files that
were
> > processed indicated 0 matched pairs. I know you reiterate this
reason in
> > the github issue you wrote, but it may be due to my lack of
> understanding.
> >
> > I'll add a uniqueness indicator and see what happens. Thanks
again for
> > your help and explanations.
> >
> > On Fri, Jul 31, 2020 at 7:49 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Ed,
> > >
> > > FYI, here's the GitHub issue I wrote up to check for this
situation and
> > > error out with a useful error message:
> > > https://github.com/NCAR/MET/issues/1439
> > >
> > > Have a great weekend.
> > >
> > > John
> > >
> > > On Fri, Jul 31, 2020 at 5:40 PM John Halley Gotway
<johnhg at ucar.edu>
> > > wrote:
> > >
> > > > Ed,
> > > >
> > > > I downloaded that log file (master_metplus.log.20200731142200)
and
> was
> > > > surprised to see that it's 79mb!
> > > >
> > > > OK, I think I know why you're getting 0 matched pairs. Since
you're
> > masks
> > > > are all named "data_mask", they're over-writing each other. So
that
> > means
> > > > that whatever mask is last (i.e. data_mask for VGTYP == 17) is
the
> only
> > > one
> > > > that's actually being applied.
> > > >
> > > > So if you regenerate your masks using the -name command line
option
> to
> > > > make them unique, then you should get matched pairs for some
of them.
> > > >
> > > > This is the line of code in Point-Stat where this happens:
> > > >
> > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
> > > >
> > > > But why would we design it in this way? The user has the
flexibility
> to
> > > > define different masking regions for different variables. But
if we
> > were
> > > to
> > > > store all of them in memory for all variables, then it'd be
very,
> very
> > > slow
> > > > and inefficient. So the code processes all of the masks for
each
> > > variable,
> > > > but only stores in memory the unique ones.
> > > >
> > > > Ideally we'd enhance Point-Stat to print a warning or error
message
> for
> > > > non-unique masking region names, but it isn't immediately
obvious to
> me
> > > > where that logic should go. But I can add a GitHub issue to
figure
> that
> > > out.
> > > >
> > > > Please let me know if fixing the mask names fixes the matched
pair
> > > problem.
> > > >
> > > > John
> > > >
> > > >
> > >
> > >
> >
> > --
> > Edward Strobach
> > EMC/NCEP/NWS/
> > IMSG Contractor
> > Cubicle#: 2029
> > 301-683-3717
> >
> >
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
Subject: success in generating masking files, but not uploading to metviewer
From: John Halley Gotway
Time: Mon Aug 03 11:52:41 2020
Great, glad to hear it. I'll go ahead and resolve this issue.
John
On Mon, Aug 3, 2020 at 11:47 AM Edward Strobach - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
>
> Good news John! Your suggestion worked and I have an abundance of
matched
> pairs after creating a unique name when running gen_vx_mask.
Although it
> took me some time to orient myself around what was being done, I
think I
> have relatively good grasp now and should be able to move forward
with all
> kinds of masking approaches. I really appreciate you taking the
time to
> help and explain things. I've learned a lot.
>
> On Mon, Aug 3, 2020 at 1:22 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Ed,
> >
> > Sounds good. I'll keep my fingers crossed that you get sane output
with
> > unique mask names.
> >
> > FYI, one easy thing to test with your existing data is
reconfiguring
> > Point-Stat to only use a single input mask file. I'd choose
whichever has
> > the largest number of mask points. So instead of listing 19
data_mask
> > files, only list one. And I'd guess that you would indeed get
output for
> > that.
> >
> > But switching to using unique masking variable names is the better
> longterm
> > solution.
> >
> > John
> >
> > On Mon, Aug 3, 2020 at 11:16 AM Edward Strobach - NOAA Affiliate
via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96043 >
> > >
> > > Hi John,
> > >
> > > I haven't pursued your suggestion yet, but will do so right now
and
> > inform
> > > you of the result as requested. I agree with your assessment
about
> > > data_mask being overwritten owing to the non-uniqueness of the
name;
> > > however, I would still have thought that matched pairs for some
of the
> > land
> > > mask files would have been realized even though only land_mask
18 was
> > > written out. I say this because the log indicates that 19
operations
> (0
> > > through 18) were performed according to the land_mask_XX.nc
dataset.
> > That
> > > means that all files were processed. However, all 19 files that
were
> > > processed indicated 0 matched pairs. I know you reiterate this
reason
> in
> > > the github issue you wrote, but it may be due to my lack of
> > understanding.
> > >
> > > I'll add a uniqueness indicator and see what happens. Thanks
again for
> > > your help and explanations.
> > >
> > > On Fri, Jul 31, 2020 at 7:49 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Ed,
> > > >
> > > > FYI, here's the GitHub issue I wrote up to check for this
situation
> and
> > > > error out with a useful error message:
> > > > https://github.com/NCAR/MET/issues/1439
> > > >
> > > > Have a great weekend.
> > > >
> > > > John
> > > >
> > > > On Fri, Jul 31, 2020 at 5:40 PM John Halley Gotway
<johnhg at ucar.edu>
> > > > wrote:
> > > >
> > > > > Ed,
> > > > >
> > > > > I downloaded that log file
(master_metplus.log.20200731142200) and
> > was
> > > > > surprised to see that it's 79mb!
> > > > >
> > > > > OK, I think I know why you're getting 0 matched pairs. Since
you're
> > > masks
> > > > > are all named "data_mask", they're over-writing each other.
So that
> > > means
> > > > > that whatever mask is last (i.e. data_mask for VGTYP == 17)
is the
> > only
> > > > one
> > > > > that's actually being applied.
> > > > >
> > > > > So if you regenerate your masks using the -name command line
option
> > to
> > > > > make them unique, then you should get matched pairs for some
of
> them.
> > > > >
> > > > > This is the line of code in Point-Stat where this happens:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/NCAR/MET/blob/0cee9fbd0b3c691fd3cf4dd1d665f5d2b0db9a37/met/src/tools/core/point_stat/point_stat_conf_info.cc#L306
> > > > >
> > > > > But why would we design it in this way? The user has the
> flexibility
> > to
> > > > > define different masking regions for different variables.
But if we
> > > were
> > > > to
> > > > > store all of them in memory for all variables, then it'd be
very,
> > very
> > > > slow
> > > > > and inefficient. So the code processes all of the masks for
each
> > > > variable,
> > > > > but only stores in memory the unique ones.
> > > > >
> > > > > Ideally we'd enhance Point-Stat to print a warning or error
message
> > for
> > > > > non-unique masking region names, but it isn't immediately
obvious
> to
> > me
> > > > > where that logic should go. But I can add a GitHub issue to
figure
> > that
> > > > out.
> > > > >
> > > > > Please let me know if fixing the mask names fixes the
matched pair
> > > > problem.
> > > > >
> > > > > John
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Edward Strobach
> > > EMC/NCEP/NWS/
> > > IMSG Contractor
> > > Cubicle#: 2029
> > > 301-683-3717
> > >
> > >
> >
> >
>
> --
> Edward Strobach
> EMC/NCEP/NWS/
> IMSG Contractor
> Cubicle#: 2029
> 301-683-3717
>
>
------------------------------------------------
More information about the Met_help
mailing list