[Met_help] [rt.rap.ucar.edu #100317] History for Verifying hail size with gridded data and SPC hail report point obs
John Opatz via RT
met_help at ucar.edu
Tue Jul 13 11:32:08 MDT 2021
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello met_help,
I’m trying to do something non-standard with MET and I’m wondering if it’s possible at all. For this thought experiment, what I’d like to do is take a 2D output grid of hailsize values, generated from our model, and compare this gridded data with the hail “point obs” from an SPC local storm report. The gridded data is daily, and I picked a day where the SPC hail size obs fit within the gridded data time period (daily; 6z to 6z). I’m trying to use the point_stat tool to generate statistics like false alarm rate, bias, etc.
For the gridded hail size data, an ncdump looks like this:
netcdf regridded {
dimensions:
lon = 7001 ;
lat = 3501 ;
variables:
double lon(lon) ;
lon:standard_name = "longitude" ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
lon:axis = "X" ;
double lat(lat) ;
lat:standard_name = "latitude" ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
lat:axis = "Y" ;
double hyhailsize(lat, lon) ;
hyhailsize:long_name = "hyhailsize" ;
hyhailsize:units = "mm" ;
hyhailsize:_FillValue = -9999. ;
hyhailsize:missing_value = -9999. ;
// global attributes:
:CDI = "Climate Data Interface version 1.9.9 (https://mpimet.mpg.de/cdi)" ;
:Conventions = "CF-1.7" ;
:agg_file_count = 287 ;
:first_volume_end_time = "2021-06-19T06:02:55Z" ;
:first_volume_start_time = "2021-06-19T05:57:12Z" ;
:minimum_file_age = "2021-06-19T05:57:12Z" ;
:maximum_file_age = "2021-06-20T06:00:47Z" ;
:aggregation_valid_time = "2021-06-20T05:40:50Z" ;
:last_volume_start_time = "2021-06-20T06:00:47Z" ;
:last_volume_end_time = "2021-06-20T06:03:37Z" ;
:history = "Wed Jun 23 15:58:13 2021: cdo remapnn,/Users/billladwig/Documents/code/git/ep-week-achilles/bladwig/src/epweek_met/config/regrid/conus.conf -selvar,hyhailsize /Users/billladwig/Documents/code/git/ep-week-achilles/bladwig/data/nrt/timeagg/20210619/hyhailsize_conus_2021-06-19T06_00_00Z_to_2021-06-20T06_00_00Z.nc /Users/billladwig/Documents/code/git/ep-week-achilles/bladwig/data/nrt/regridded/20210619/regridded.nc" ;
:CDO = "Climate Data Operators version 1.9.9 (https://mpimet.mpg.de/cdo)" ;
}
Assuming it is possible to do this, I’m not quite sure how to handle the SPC hail observations. Attached is the ASCII Point Observation Format file that I’m feeding in to the ASCII2NC tool, which produces a NetCDF file (the column values in the csv file may be incorrect and I can change that as needed).
Also attached is my first attempt at a configuration file, so it’s not right. The part that isn’t clear to me is how to set up the ASCII2NC NetCDF obs file to be treated like “point obs” compared against the grid. I’m not sure what to use for the “level” section, since the output from ASCII2NC is 1D variables. In the attached config, errors are thrown for not being able to parse the level. If I leave the “obs” section out of the file, I get errors indicating that I need the same number of field entries as “fcst” section.
Any tips you might have would be greatly appreciated.
Regards,
Bill Ladwig
________________________________
This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.
________________________________
Xactware's opt-in mailing list allows you to receive Xactware News that is of interest to you. Visit my.xactware.com today to join or to update your email preferences!
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Verifying hail size with gridded data and SPC hail report point obs
From: John Opatz
Time: Fri Jun 25 10:55:30 2021
Hi Bill,
Thanks for sending along your observation data. The great news is,
they're
already in a format that ASCII2NC is capable of handling (11 columns,
in
the format shown in Table 6.4
<https://met.readthedocs.io/en/latest/Users_Guide/reformat_point.html#id8>).
The configuration file for the ASCII2NC tool is only necessary if you
want
a time summary or user-specific message type mapping. In your case, I
think
you'll be OK just calling the tool:
ascii2nc spc_obs.csv your_output_file.nc
I did a quick check of the results and I think you'll be able to work
with
them.
The next step would be to compare them with your gridded model hail
size
data. The easiest tool for that would be PointStat: take a look at the
user
guide entry here
<https://met.readthedocs.io/en/latest/Users_Guide/point-
stat.html#point-stat-tool>
for some information. The ncdump results for your forecast data look
like
it'll be an easy read-in for the PointStat tool, and you already know
your
point data will be read in, since it's a product of MET.
If you run into any issues, feel free to reply and we'll assist you
further.
-John O.
On Wed, Jun 23, 2021 at 6:27 PM Ladwig, William via RT
<met_help at ucar.edu>
wrote:
>
> Wed Jun 23 18:27:44 2021: Request 100317 was acted upon.
> Transaction: Ticket created by William.Ladwig at verisk.com
> Queue: met_help
> Subject: Verifying hail size with gridded data and SPC hail
report
> point obs
> Owner: Nobody
> Requestors: William.Ladwig at verisk.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317 >
>
>
> Hello met_help,
>
> I’m trying to do something non-standard with MET and I’m wondering
if it’s
> possible at all. For this thought experiment, what I’d like to do is
take a
> 2D output grid of hailsize values, generated from our model, and
compare
> this gridded data with the hail “point obs” from an SPC local storm
report.
> The gridded data is daily, and I picked a day where the SPC hail
size obs
> fit within the gridded data time period (daily; 6z to 6z). I’m
trying to
> use the point_stat tool to generate statistics like false alarm
rate, bias,
> etc.
>
> For the gridded hail size data, an ncdump looks like this:
>
>
> netcdf regridded {
>
> dimensions:
>
> lon = 7001 ;
>
> lat = 3501 ;
>
> variables:
>
> double lon(lon) ;
>
> lon:standard_name = "longitude" ;
>
> lon:long_name = "longitude" ;
>
> lon:units = "degrees_east" ;
>
> lon:axis = "X" ;
>
> double lat(lat) ;
>
> lat:standard_name = "latitude" ;
>
> lat:long_name = "latitude" ;
>
> lat:units = "degrees_north" ;
>
> lat:axis = "Y" ;
>
> double hyhailsize(lat, lon) ;
>
> hyhailsize:long_name = "hyhailsize" ;
>
> hyhailsize:units = "mm" ;
>
> hyhailsize:_FillValue = -9999. ;
>
> hyhailsize:missing_value = -9999. ;
>
>
>
> // global attributes:
>
> :CDI = "Climate Data Interface version 1.9.9 (
> https://mpimet.mpg.de/cdi)" ;
>
> :Conventions = "CF-1.7" ;
>
> :agg_file_count = 287 ;
>
> :first_volume_end_time = "2021-06-19T06:02:55Z" ;
>
> :first_volume_start_time = "2021-06-19T05:57:12Z" ;
>
> :minimum_file_age = "2021-06-19T05:57:12Z" ;
>
> :maximum_file_age = "2021-06-20T06:00:47Z" ;
>
> :aggregation_valid_time = "2021-06-20T05:40:50Z" ;
>
> :last_volume_start_time = "2021-06-20T06:00:47Z" ;
>
> :last_volume_end_time = "2021-06-20T06:03:37Z" ;
>
> :history = "Wed Jun 23 15:58:13 2021: cdo
> remapnn,/Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/src/epweek_met/config/regrid/conus.conf
> -selvar,hyhailsize
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/timeagg/20210619/hyhailsize_conus_2021-06-
19T06_00_00Z_to_2021-06-20T06_00_00Z.nc
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/regridded/20210619/
> regridded.nc" ;
>
> :CDO = "Climate Data Operators version 1.9.9 (
> https://mpimet.mpg.de/cdo)" ;
>
> }
>
> Assuming it is possible to do this, I’m not quite sure how to handle
the
> SPC hail observations. Attached is the ASCII Point Observation
Format file
> that I’m feeding in to the ASCII2NC tool, which produces a NetCDF
file (the
> column values in the csv file may be incorrect and I can change that
as
> needed).
>
> Also attached is my first attempt at a configuration file, so it’s
not
> right. The part that isn’t clear to me is how to set up the ASCII2NC
NetCDF
> obs file to be treated like “point obs” compared against the grid.
I’m not
> sure what to use for the “level” section, since the output from
ASCII2NC is
> 1D variables. In the attached config, errors are thrown for not
being able
> to parse the level. If I leave the “obs” section out of the file, I
get
> errors indicating that I need the same number of field entries as
“fcst”
> section.
>
> Any tips you might have would be greatly appreciated.
>
> Regards,
>
> Bill Ladwig
>
> ________________________________
>
> This email is intended solely for the recipient. It may contain
> privileged, proprietary or confidential information or material. If
you are
> not the intended recipient, please delete this email and any
attachments
> and notify the sender of the error.
>
> ________________________________
>
> Xactware's opt-in mailing list allows you to receive Xactware News
that is
> of interest to you. Visit my.xactware.com today to join or to update
your
> email preferences!
>
>
--
John Opatz
Associate Scientist III
NCAR RAL and DTC
Boulder, Colorado
+1 303-497-8305
------------------------------------------------
Subject: Verifying hail size with gridded data and SPC hail report point obs
From: Ladwig, William
Time: Fri Jun 25 16:28:15 2021
Hi John,
Thank you for your reply. The problem I was having was with what to
use in the configuration file for the “obs” section, when the input is
a non-standard NetCDF-CF fcst file along with handmade ASCII obs.
If I use ASCII2NC to create the NetCDF_MET file for the obs, and leave
the “obs” section out of the configuration file, I get an error
stating that the number of field entries in the “fcst” section does
not match the number of field entries in the “obs” section. Instead,
if I include an “obs” section and try to specify that the
“message_type” should use NETCDF_MET, I’m not sure how to configure
the “field” section, since it throws errors saying it can’t parse the
“field” {tried using obs_val with a field of “(*)”}.
I also had a possibly related issue where I specified the “valid_time”
for the “fcst” grid section, since it is not in the NetCDF file. But,
upon parsing the file, it seemed to always default to a time of 0, or
the January 1, 1970 epoch. In other words, it didn’t honor my setting
in the config file (maybe a bug with the generic CF reader?) This
might be the source of some of the other problems with my use a
point_stat.
Ultimately, I gave up on using point_stat, and instead put the
observations on a grid and ran grid_stat. I just wanted to get
something that doesn’t throw errors, and that seemed to work. I was
only given a few days to try this out, so I’ll have to revisit
point_stat again in the future.
Best regards,
Bill
From: John Opatz via RT <met_help at ucar.edu>
Date: Friday, June 25, 2021 at 10:55 AM
To: Ladwig, William <William.Ladwig at verisk.com>
Subject: Re: [rt.rap.ucar.edu #100317] Verifying hail size with
gridded data and SPC hail report point obs
Caution: This email originated outside of the organization
Hi Bill,
Thanks for sending along your observation data. The great news is,
they're
already in a format that ASCII2NC is capable of handling (11 columns,
in
the format shown in Table 6.4
<https://urldefense.com/v3/__https://met.readthedocs.io/en/latest/Users_Guide/reformat_point.html*id8__;Iw!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF626mW9_xx$ >).
The configuration file for the ASCII2NC tool is only necessary if you
want
a time summary or user-specific message type mapping. In your case, I
think
you'll be OK just calling the tool:
ascii2nc spc_obs.csv your_output_file.nc
I did a quick check of the results and I think you'll be able to work
with
them.
The next step would be to compare them with your gridded model hail
size
data. The easiest tool for that would be PointStat: take a look at the
user
guide entry here
<https://urldefense.com/v3/__https://met.readthedocs.io/en/latest/Users_Guide/point-
stat.html*point-stat-tool__;Iw!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF622Iw8shK$ >
for some information. The ncdump results for your forecast data look
like
it'll be an easy read-in for the PointStat tool, and you already know
your
point data will be read in, since it's a product of MET.
If you run into any issues, feel free to reply and we'll assist you
further.
-John O.
On Wed, Jun 23, 2021 at 6:27 PM Ladwig, William via RT
<met_help at ucar.edu>
wrote:
>
> Wed Jun 23 18:27:44 2021: Request 100317 was acted upon.
> Transaction: Ticket created by William.Ladwig at verisk.com
> Queue: met_help
> Subject: Verifying hail size with gridded data and SPC hail
report
> point obs
> Owner: Nobody
> Requestors: William.Ladwig at verisk.com
> Status: new
> Ticket <URL:
https://urldefense.com/v3/__https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF624AJkF8v$<https://urldefense.com/v3/__https:/rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF624AJkF8v$> >
>
>
> Hello met_help,
>
> I’m trying to do something non-standard with MET and I’m wondering
if it’s
> possible at all. For this thought experiment, what I’d like to do is
take a
> 2D output grid of hailsize values, generated from our model, and
compare
> this gridded data with the hail “point obs” from an SPC local storm
report.
> The gridded data is daily, and I picked a day where the SPC hail
size obs
> fit within the gridded data time period (daily; 6z to 6z). I’m
trying to
> use the point_stat tool to generate statistics like false alarm
rate, bias,
> etc.
>
> For the gridded hail size data, an ncdump looks like this:
>
>
> netcdf regridded {
>
> dimensions:
>
> lon = 7001 ;
>
> lat = 3501 ;
>
> variables:
>
> double lon(lon) ;
>
> lon:standard_name = "longitude" ;
>
> lon:long_name = "longitude" ;
>
> lon:units = "degrees_east" ;
>
> lon:axis = "X" ;
>
> double lat(lat) ;
>
> lat:standard_name = "latitude" ;
>
> lat:long_name = "latitude" ;
>
> lat:units = "degrees_north" ;
>
> lat:axis = "Y" ;
>
> double hyhailsize(lat, lon) ;
>
> hyhailsize:long_name = "hyhailsize" ;
>
> hyhailsize:units = "mm" ;
>
> hyhailsize:_FillValue = -9999. ;
>
> hyhailsize:missing_value = -9999. ;
>
>
>
> // global attributes:
>
> :CDI = "Climate Data Interface version 1.9.9 (
>
https://urldefense.com/v3/__https://mpimet.mpg.de/cdi__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621wlZRKd$<https://urldefense.com/v3/__https:/mpimet.mpg.de/cdi__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621wlZRKd$> )" ;
>
> :Conventions = "CF-1.7" ;
>
> :agg_file_count = 287 ;
>
> :first_volume_end_time = "2021-06-19T06:02:55Z" ;
>
> :first_volume_start_time = "2021-06-19T05:57:12Z" ;
>
> :minimum_file_age = "2021-06-19T05:57:12Z" ;
>
> :maximum_file_age = "2021-06-20T06:00:47Z" ;
>
> :aggregation_valid_time = "2021-06-20T05:40:50Z" ;
>
> :last_volume_start_time = "2021-06-20T06:00:47Z" ;
>
> :last_volume_end_time = "2021-06-20T06:03:37Z" ;
>
> :history = "Wed Jun 23 15:58:13 2021: cdo
> remapnn,/Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/src/epweek_met/config/regrid/conus.conf
> -selvar,hyhailsize
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/timeagg/20210619/hyhailsize_conus_2021-06-
19T06_00_00Z_to_2021-06-20T06_00_00Z.nc
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/regridded/20210619/
> regridded.nc" ;
>
> :CDO = "Climate Data Operators version 1.9.9 (
>
https://urldefense.com/v3/__https://mpimet.mpg.de/cdo__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621uQSYRz$<https://urldefense.com/v3/__https:/mpimet.mpg.de/cdo__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621uQSYRz$> )" ;
>
> }
>
> Assuming it is possible to do this, I’m not quite sure how to handle
the
> SPC hail observations. Attached is the ASCII Point Observation
Format file
> that I’m feeding in to the ASCII2NC tool, which produces a NetCDF
file (the
> column values in the csv file may be incorrect and I can change that
as
> needed).
>
> Also attached is my first attempt at a configuration file, so it’s
not
> right. The part that isn’t clear to me is how to set up the ASCII2NC
NetCDF
> obs file to be treated like “point obs” compared against the grid.
I’m not
> sure what to use for the “level” section, since the output from
ASCII2NC is
> 1D variables. In the attached config, errors are thrown for not
being able
> to parse the level. If I leave the “obs” section out of the file, I
get
> errors indicating that I need the same number of field entries as
“fcst”
> section.
>
> Any tips you might have would be greatly appreciated.
>
> Regards,
>
> Bill Ladwig
>
> ________________________________
>
> This email is intended solely for the recipient. It may contain
> privileged, proprietary or confidential information or material. If
you are
> not the intended recipient, please delete this email and any
attachments
> and notify the sender of the error.
>
> ________________________________
>
> Xactware's opt-in mailing list allows you to receive Xactware News
that is
> of interest to you. Visit my.xactware.com today to join or to update
your
> email preferences!
>
>
--
John Opatz
Associate Scientist III
NCAR RAL and DTC
Boulder, Colorado
+1 303-497-8305
________________________________
This email is intended solely for the recipient. It may contain
privileged, proprietary or confidential information or material. If
you are not the intended recipient, please delete this email and any
attachments and notify the sender of the error.
________________________________
Xactware's opt-in mailing list allows you to receive Xactware News
that is of interest to you. Visit my.xactware.com today to join or to
update your email preferences!
------------------------------------------------
Subject: Verifying hail size with gridded data and SPC hail report point obs
From: John Opatz
Time: Tue Jun 29 09:15:50 2021
Hi Bill,
I'm including Tina on this email thread, as she has some experience
working with hail data inside MET.
Tina, do we have an example use case that might be of some help? It'd
be
good to have an illustration of using MET to read in an ASCII2NC
generated
file as the observation dataset, or a generalized PointStat use case;
one
that uses hail data would be even better.
Thanks,
-John O.
On Fri, Jun 25, 2021 at 4:28 PM Ladwig, William via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317 >
>
> Hi John,
>
> Thank you for your reply. The problem I was having was with what to
use in
> the configuration file for the “obs” section, when the input is a
> non-standard NetCDF-CF fcst file along with handmade ASCII obs.
>
> If I use ASCII2NC to create the NetCDF_MET file for the obs, and
leave the
> “obs” section out of the configuration file, I get an error stating
that
> the number of field entries in the “fcst” section does not match the
number
> of field entries in the “obs” section. Instead, if I include an
“obs”
> section and try to specify that the “message_type” should use
NETCDF_MET,
> I’m not sure how to configure the “field” section, since it throws
errors
> saying it can’t parse the “field” {tried using obs_val with a field
of
> “(*)”}.
>
> I also had a possibly related issue where I specified the
“valid_time” for
> the “fcst” grid section, since it is not in the NetCDF file. But,
upon
> parsing the file, it seemed to always default to a time of 0, or the
> January 1, 1970 epoch. In other words, it didn’t honor my setting in
the
> config file (maybe a bug with the generic CF reader?) This might be
the
> source of some of the other problems with my use a point_stat.
>
> Ultimately, I gave up on using point_stat, and instead put the
> observations on a grid and ran grid_stat. I just wanted to get
something
> that doesn’t throw errors, and that seemed to work. I was only given
a few
> days to try this out, so I’ll have to revisit point_stat again in
the
> future.
>
> Best regards,
>
> Bill
>
> From: John Opatz via RT <met_help at ucar.edu>
> Date: Friday, June 25, 2021 at 10:55 AM
> To: Ladwig, William <William.Ladwig at verisk.com>
> Subject: Re: [rt.rap.ucar.edu #100317] Verifying hail size with
gridded
> data and SPC hail report point obs
> Caution: This email originated outside of the organization
>
> Hi Bill,
>
> Thanks for sending along your observation data. The great news is,
they're
> already in a format that ASCII2NC is capable of handling (11
columns, in
> the format shown in Table 6.4
> <
>
https://urldefense.com/v3/__https://met.readthedocs.io/en/latest/Users_Guide/reformat_point.html*id8__;Iw!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF626mW9_xx$
> >).
> The configuration file for the ASCII2NC tool is only necessary if
you want
> a time summary or user-specific message type mapping. In your case,
I think
> you'll be OK just calling the tool:
>
> ascii2nc spc_obs.csv your_output_file.nc
>
> I did a quick check of the results and I think you'll be able to
work with
> them.
>
> The next step would be to compare them with your gridded model hail
size
> data. The easiest tool for that would be PointStat: take a look at
the user
> guide entry here
> <
>
https://urldefense.com/v3/__https://met.readthedocs.io/en/latest/Users_Guide/point-
stat.html*point-stat-tool__;Iw!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF622Iw8shK$
> >
> for some information. The ncdump results for your forecast data look
like
> it'll be an easy read-in for the PointStat tool, and you already
know your
> point data will be read in, since it's a product of MET.
>
> If you run into any issues, feel free to reply and we'll assist you
> further.
>
> -John O.
>
> On Wed, Jun 23, 2021 at 6:27 PM Ladwig, William via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Wed Jun 23 18:27:44 2021: Request 100317 was acted upon.
> > Transaction: Ticket created by William.Ladwig at verisk.com
> > Queue: met_help
> > Subject: Verifying hail size with gridded data and SPC hail
report
> > point obs
> > Owner: Nobody
> > Requestors: William.Ladwig at verisk.com
> > Status: new
> > Ticket <URL:
>
https://urldefense.com/v3/__https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF624AJkF8v$
> <
>
https://urldefense.com/v3/__https:/rt.rap.ucar.edu/rt/Ticket/Display.html?id=100317__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF624AJkF8v$>
> >
> >
> >
> > Hello met_help,
> >
> > I’m trying to do something non-standard with MET and I’m wondering
if
> it’s
> > possible at all. For this thought experiment, what I’d like to do
is
> take a
> > 2D output grid of hailsize values, generated from our model, and
compare
> > this gridded data with the hail “point obs” from an SPC local
storm
> report.
> > The gridded data is daily, and I picked a day where the SPC hail
size obs
> > fit within the gridded data time period (daily; 6z to 6z). I’m
trying to
> > use the point_stat tool to generate statistics like false alarm
rate,
> bias,
> > etc.
> >
> > For the gridded hail size data, an ncdump looks like this:
> >
> >
> > netcdf regridded {
> >
> > dimensions:
> >
> > lon = 7001 ;
> >
> > lat = 3501 ;
> >
> > variables:
> >
> > double lon(lon) ;
> >
> > lon:standard_name = "longitude" ;
> >
> > lon:long_name = "longitude" ;
> >
> > lon:units = "degrees_east" ;
> >
> > lon:axis = "X" ;
> >
> > double lat(lat) ;
> >
> > lat:standard_name = "latitude" ;
> >
> > lat:long_name = "latitude" ;
> >
> > lat:units = "degrees_north" ;
> >
> > lat:axis = "Y" ;
> >
> > double hyhailsize(lat, lon) ;
> >
> > hyhailsize:long_name = "hyhailsize" ;
> >
> > hyhailsize:units = "mm" ;
> >
> > hyhailsize:_FillValue = -9999. ;
> >
> > hyhailsize:missing_value = -9999. ;
> >
> >
> >
> > // global attributes:
> >
> > :CDI = "Climate Data Interface version 1.9.9 (
> >
>
https://urldefense.com/v3/__https://mpimet.mpg.de/cdi__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621wlZRKd$
> <
>
https://urldefense.com/v3/__https:/mpimet.mpg.de/cdi__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621wlZRKd$>
> )" ;
> >
> > :Conventions = "CF-1.7" ;
> >
> > :agg_file_count = 287 ;
> >
> > :first_volume_end_time = "2021-06-19T06:02:55Z" ;
> >
> > :first_volume_start_time = "2021-06-19T05:57:12Z" ;
> >
> > :minimum_file_age = "2021-06-19T05:57:12Z" ;
> >
> > :maximum_file_age = "2021-06-20T06:00:47Z" ;
> >
> > :aggregation_valid_time = "2021-06-20T05:40:50Z" ;
> >
> > :last_volume_start_time = "2021-06-20T06:00:47Z" ;
> >
> > :last_volume_end_time = "2021-06-20T06:03:37Z" ;
> >
> > :history = "Wed Jun 23 15:58:13 2021: cdo
> >
> remapnn,/Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/src/epweek_met/config/regrid/conus.conf
> > -selvar,hyhailsize
> >
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/timeagg/20210619/hyhailsize_conus_2021-06-
19T06_00_00Z_to_2021-06-20T06_00_00Z.nc
> >
> /Users/billladwig/Documents/code/git/ep-week-
achilles/bladwig/data/nrt/regridded/20210619/
> > regridded.nc" ;
> >
> > :CDO = "Climate Data Operators version 1.9.9 (
> >
>
https://urldefense.com/v3/__https://mpimet.mpg.de/cdo__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621uQSYRz$
> <
>
https://urldefense.com/v3/__https:/mpimet.mpg.de/cdo__;!!CAFLEWIB!X3wGsaa_VxoqSZ0wPdIlnG-
phduzaFSiuicvID7suvsDIsTdWSZ7HlEJZnF621uQSYRz$>
> )" ;
> >
> > }
> >
> > Assuming it is possible to do this, I’m not quite sure how to
handle the
> > SPC hail observations. Attached is the ASCII Point Observation
Format
> file
> > that I’m feeding in to the ASCII2NC tool, which produces a NetCDF
file
> (the
> > column values in the csv file may be incorrect and I can change
that as
> > needed).
> >
> > Also attached is my first attempt at a configuration file, so it’s
not
> > right. The part that isn’t clear to me is how to set up the
ASCII2NC
> NetCDF
> > obs file to be treated like “point obs” compared against the grid.
I’m
> not
> > sure what to use for the “level” section, since the output from
ASCII2NC
> is
> > 1D variables. In the attached config, errors are thrown for not
being
> able
> > to parse the level. If I leave the “obs” section out of the file,
I get
> > errors indicating that I need the same number of field entries as
“fcst”
> > section.
> >
> > Any tips you might have would be greatly appreciated.
> >
> > Regards,
> >
> > Bill Ladwig
> >
> > ________________________________
> >
> > This email is intended solely for the recipient. It may contain
> > privileged, proprietary or confidential information or material.
If you
> are
> > not the intended recipient, please delete this email and any
attachments
> > and notify the sender of the error.
> >
> > ________________________________
> >
> > Xactware's opt-in mailing list allows you to receive Xactware News
that
> is
> > of interest to you. Visit my.xactware.com today to join or to
update
> your
> > email preferences!
> >
> >
>
> --
> John Opatz
> Associate Scientist III
> NCAR RAL and DTC
> Boulder, Colorado
> +1 303-497-8305
>
> ________________________________
>
> This email is intended solely for the recipient. It may contain
> privileged, proprietary or confidential information or material. If
you are
> not the intended recipient, please delete this email and any
attachments
> and notify the sender of the error.
>
> ________________________________
>
> Xactware's opt-in mailing list allows you to receive Xactware News
that is
> of interest to you. Visit my.xactware.com today to join or to update
your
> email preferences!
>
>
--
John Opatz
Associate Scientist III
NCAR RAL and DTC
Boulder, Colorado
+1 303-497-8305
------------------------------------------------
More information about the Met_help
mailing list