[Met_help] [rt.rap.ucar.edu #93678] History for ensemble verification with MET

John Halley Gotway via RT met_help at ucar.edu
Wed Apr 1 11:09:58 MDT 2020


----------------------------------------------------------------
  Initial Request
----------------------------------------------------------------

Hello,

Happy New Year. This is Binyu from NCEP/EMC and I need help to use MET 
for ensemble verification.

My forecast data is under:

/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001 
(and cgrib2.002, ..cgrib2.005)

My obs. data is::

/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-070500_2008221-152000.netcdf

  I am trying to evaluate "VAFTD" from forecast data versus 
"ASH_MASS_LOADING" in the obs. files.  There are two problems:

1.It seems my NetCDF can not be read by MET directly. It is classic 
format, but MET can not read it.

2.The unit conversion also needs to be considered: if we assume the unit 
from Forecast is F, unit from obs. is Obs, then

Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)

It seems hat the input model and observation datasets needs to be on the 
same grid, How to do that?

Thank you very much for help.

Binyu



----------------------------------------------------------------
  Complete Ticket History
----------------------------------------------------------------

Subject: ensemble verification with MET
From: John Halley Gotway
Time: Mon Jan 06 16:03:44 2020

Binyu,

I grabbed your data and am taking a look.  I see that your NetCDF file
is
on a polar stereographic projection, but I don't see the definition of
that
grid.  I do see the lat/lon fields but MET actually needs the
parameters to
define the projection itself.

Any idea what those are?

Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.

How do you ultimately want to do the comparison?  Regrid the forecast
to
the observation domain?  Or vice-versa?

Either way, we do still need to know how that polar stereographic grid
is
defined.

Thanks,
John

On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:

>
> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> Transaction: Ticket created by binyu.wang at noaa.gov
>        Queue: met_help
>      Subject: ensemble verification with MET
>        Owner: Nobody
>   Requestors: binyu.wang at noaa.gov
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>
>
> Hello,
>
> Happy New Year. This is Binyu from NCEP/EMC and I need help to use
MET
> for ensemble verification.
>
> My forecast data is under:
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>
> (and cgrib2.002, ..cgrib2.005)
>
> My obs. data is::
>
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>
>   I am trying to evaluate "VAFTD" from forecast data versus
> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>
> 1.It seems my NetCDF can not be read by MET directly. It is classic
> format, but MET can not read it.
>
> 2.The unit conversion also needs to be considered: if we assume the
unit
> from Forecast is F, unit from obs. is Obs, then
>
> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>
> It seems hat the input model and observation datasets needs to be on
the
> same grid, How to do that?
>
> Thank you very much for help.
>
> Binyu
>
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #93678] ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Tue Jan 07 08:03:27 2020

John,

Thank you for your time. I plan to re-grid the model data to the
observation grid as MET suggested.

I will contact people who gave me the NetCDF data and let you know
later.

Binyu

On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> Binyu,
>
> I grabbed your data and am taking a look.  I see that your NetCDF
file is
> on a polar stereographic projection, but I don't see the definition
of that
> grid.  I do see the lat/lon fields but MET actually needs the
parameters to
> define the projection itself.
>
> Any idea what those are?
>
> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
>
> How do you ultimately want to do the comparison?  Regrid the
forecast to
> the observation domain?  Or vice-versa?
>
> Either way, we do still need to know how that polar stereographic
grid is
> defined.
>
> Thanks,
> John
>
> On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>> Transaction: Ticket created by binyu.wang at noaa.gov
>>         Queue: met_help
>>       Subject: ensemble verification with MET
>>         Owner: Nobody
>>    Requestors: binyu.wang at noaa.gov
>>        Status: new
>>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>
>>
>> Hello,
>>
>> Happy New Year. This is Binyu from NCEP/EMC and I need help to use
MET
>> for ensemble verification.
>>
>> My forecast data is under:
>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>
>> (and cgrib2.002, ..cgrib2.005)
>>
>> My obs. data is::
>>
>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>
>>    I am trying to evaluate "VAFTD" from forecast data versus
>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>>
>> 1.It seems my NetCDF can not be read by MET directly. It is classic
>> format, but MET can not read it.
>>
>> 2.The unit conversion also needs to be considered: if we assume the
unit
>> from Forecast is F, unit from obs. is Obs, then
>>
>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>
>> It seems hat the input model and observation datasets needs to be
on the
>> same grid, How to do that?
>>
>> Thank you very much for help.
>>
>> Binyu
>>
>>
>>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #93678] ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Tue Jan 07 08:38:40 2020

Hello John,

Do you have an example of the NetCDF file that can be read by MET?
Thank
you.

Binyu

On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> Binyu,
>
> I grabbed your data and am taking a look.  I see that your NetCDF
file is
> on a polar stereographic projection, but I don't see the definition
of that
> grid.  I do see the lat/lon fields but MET actually needs the
parameters to
> define the projection itself.
>
> Any idea what those are?
>
> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
>
> How do you ultimately want to do the comparison?  Regrid the
forecast to
> the observation domain?  Or vice-versa?
>
> Either way, we do still need to know how that polar stereographic
grid is
> defined.
>
> Thanks,
> John
>
> On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>> Transaction: Ticket created by binyu.wang at noaa.gov
>>         Queue: met_help
>>       Subject: ensemble verification with MET
>>         Owner: Nobody
>>    Requestors: binyu.wang at noaa.gov
>>        Status: new
>>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>
>>
>> Hello,
>>
>> Happy New Year. This is Binyu from NCEP/EMC and I need help to use
MET
>> for ensemble verification.
>>
>> My forecast data is under:
>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>
>> (and cgrib2.002, ..cgrib2.005)
>>
>> My obs. data is::
>>
>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>
>>    I am trying to evaluate "VAFTD" from forecast data versus
>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>>
>> 1.It seems my NetCDF can not be read by MET directly. It is classic
>> format, but MET can not read it.
>>
>> 2.The unit conversion also needs to be considered: if we assume the
unit
>> from Forecast is F, unit from obs. is Obs, then
>>
>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>
>> It seems hat the input model and observation datasets needs to be
on the
>> same grid, How to do that?
>>
>> Thank you very much for help.
>>
>> Binyu
>>
>>
>>

------------------------------------------------
Subject: ensemble verification with MET
From: John Halley Gotway
Time: Tue Jan 07 09:46:23 2020

Binyu,

You have 3 options:
(1) Use MET's internal NetCDF file format.
(2) Follow the NetCDF Climate Forecast conventions.
(3) Use python embedding to define the projection information and pass
the
data in memory to MET.

Perhaps option (1) is most simple.  To generate an example, I used a
sample
GFS file in GRIB format and ran MET's regrid_data_plane tool to put it
on a
known Polar Stereographic grid.  From the list of EMC grids, I picked
grid
number 5:
https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html

And ran this command:
*   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib G005
gfs_G005.nc -field 'name="PRMSL"; level="L0";'*

Then I ran plot_data_plane to make sure the result looks reasonable:
*    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
'name="PRMSL_L0"; level="(*,*)";'*

I've attached a PNG of the resulting plot and the NetCDF file itself.
If
you mimic this conventions of this file, it should be readable by MET.

Thanks,
John


On Tue, Jan 7, 2020 at 8:39 AM binyu.wang at noaa.gov via RT
<met_help at ucar.edu>
wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>
> Hello John,
>
> Do you have an example of the NetCDF file that can be read by MET?
Thank
> you.
>
> Binyu
>
> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> > Binyu,
> >
> > I grabbed your data and am taking a look.  I see that your NetCDF
file is
> > on a polar stereographic projection, but I don't see the
definition of
> that
> > grid.  I do see the lat/lon fields but MET actually needs the
parameters
> to
> > define the projection itself.
> >
> > Any idea what those are?
> >
> > Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
> >
> > How do you ultimately want to do the comparison?  Regrid the
forecast to
> > the observation domain?  Or vice-versa?
> >
> > Either way, we do still need to know how that polar stereographic
grid is
> > defined.
> >
> > Thanks,
> > John
> >
> > On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> >> Transaction: Ticket created by binyu.wang at noaa.gov
> >>         Queue: met_help
> >>       Subject: ensemble verification with MET
> >>         Owner: Nobody
> >>    Requestors: binyu.wang at noaa.gov
> >>        Status: new
> >>   Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
> >
> >>
> >>
> >> Hello,
> >>
> >> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use MET
> >> for ensemble verification.
> >>
> >> My forecast data is under:
> >>
> >>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
> >>
> >> (and cgrib2.002, ..cgrib2.005)
> >>
> >> My obs. data is::
> >>
> >>
> >>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
> >>
> >>    I am trying to evaluate "VAFTD" from forecast data versus
> >> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
> >>
> >> 1.It seems my NetCDF can not be read by MET directly. It is
classic
> >> format, but MET can not read it.
> >>
> >> 2.The unit conversion also needs to be considered: if we assume
the unit
> >> from Forecast is F, unit from obs. is Obs, then
> >>
> >> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
> >>
> >> It seems hat the input model and observation datasets needs to be
on the
> >> same grid, How to do that?
> >>
> >> Thank you very much for help.
> >>
> >> Binyu
> >>
> >>
> >>
>
>

------------------------------------------------
Subject: ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Tue Jan 07 21:32:42 2020

Hello John,


Thank you. I got new questions using "regrid_data_plane",  (please see
the error message below).


1. There is only one layer in my NetCDF file, so the level="L0"?

2. The error message is due to "polar stereographic grid is missing?"

3. "To_grid (G005 in your example)" is decided by the polar
stereographic grid or not?


Thank you very much!

Binyu



$ regrid_data_plane Kasatochi_2008221-181500_2008222-005500.netcdf
G223 test.nc -field 'name="ASH_MASS_LOADING"; level="L0";'

DEBUG 1: Reading data file: Kasatochi_2008221-181500_2008222-
005500.netcdf

WARNING:

WARNING: read_netcdf_grid() -> Applying METv2.0 grid parsing logic
since the "MET_version" global attribute is not present.

WARNING:

WARNING:

WARNING: read_netcdf_grid() -> Applying METv2.0 grid parsing logic
since the "MET_version" global attribute is not present.

WARNING:

DEBUG 2: Input grid: Projection: Stereographic Nx: -9999 Ny: -9999
IsNorthHemisphere: true Lon_orient: 9999.000 Bx: 0.000 By: 0.156
Alpha: 1.9877

DEBUG 2: Output grid: Projection: Stereographic Nx: 129 Ny: 129
IsNorthHemisphere: true Lon_orient: 105.000 Bx: 64.000 By: 64.000
Alpha: 62.4085

DEBUG 2: Interpolation options: method = NEAREST, width = 1, shape =
SQUARE, vld_thresh = 0.5

ERROR  :

ERROR  : MetNcFile::data(NcVar *, const LongArray &, DataPlane &)
const ->  star found in bad slot

ERROR  :


On Tue, Jan 7, 2020 at 11:46 AM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:

> Binyu,
>
> You have 3 options:
> (1) Use MET's internal NetCDF file format.
> (2) Follow the NetCDF Climate Forecast conventions.
> (3) Use python embedding to define the projection information and
pass the
> data in memory to MET.
>
> Perhaps option (1) is most simple.  To generate an example, I used a
sample
> GFS file in GRIB format and ran MET's regrid_data_plane tool to put
it on a
> known Polar Stereographic grid.  From the list of EMC grids, I
picked grid
> number 5:
> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>
> And ran this command:
> *   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib
G005
> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>
> Then I ran plot_data_plane to make sure the result looks reasonable:
> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
> 'name="PRMSL_L0"; level="(*,*)";'*
>
> I've attached a PNG of the resulting plot and the NetCDF file
itself.  If
> you mimic this conventions of this file, it should be readable by
MET.
>
> Thanks,
> John
>
>
> On Tue, Jan 7, 2020 at 8:39 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
> >
> > Hello John,
> >
> > Do you have an example of the NetCDF file that can be read by MET?
Thank
> > you.
> >
> > Binyu
> >
> > On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> > > Binyu,
> > >
> > > I grabbed your data and am taking a look.  I see that your
NetCDF file
> is
> > > on a polar stereographic projection, but I don't see the
definition of
> > that
> > > grid.  I do see the lat/lon fields but MET actually needs the
> parameters
> > to
> > > define the projection itself.
> > >
> > > Any idea what those are?
> > >
> > > Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
> > >
> > > How do you ultimately want to do the comparison?  Regrid the
forecast
> to
> > > the observation domain?  Or vice-versa?
> > >
> > > Either way, we do still need to know how that polar
stereographic grid
> is
> > > defined.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> > >> Transaction: Ticket created by binyu.wang at noaa.gov
> > >>         Queue: met_help
> > >>       Subject: ensemble verification with MET
> > >>         Owner: Nobody
> > >>    Requestors: binyu.wang at noaa.gov
> > >>        Status: new
> > >>   Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
> > >
> > >>
> > >>
> > >> Hello,
> > >>
> > >> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use MET
> > >> for ensemble verification.
> > >>
> > >> My forecast data is under:
> > >>
> > >>
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
> > >>
> > >> (and cgrib2.002, ..cgrib2.005)
> > >>
> > >> My obs. data is::
> > >>
> > >>
> > >>
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
> > >>
> > >>    I am trying to evaluate "VAFTD" from forecast data versus
> > >> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
> > >>
> > >> 1.It seems my NetCDF can not be read by MET directly. It is
classic
> > >> format, but MET can not read it.
> > >>
> > >> 2.The unit conversion also needs to be considered: if we assume
the
> unit
> > >> from Forecast is F, unit from obs. is Obs, then
> > >>
> > >> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
> > >>
> > >> It seems hat the input model and observation datasets needs to
be on
> the
> > >> same grid, How to do that?
> > >>
> > >> Thank you very much for help.
> > >>
> > >> Binyu
> > >>
> > >>
> > >>
> >
> >
>
>

------------------------------------------------
Subject: ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Wed Jan 08 13:34:56 2020

Hello John,

I got the parameters used for the projection in the NetCDF file
(please
see below). How to apply the information so MET can read the NetCDF
for
ensemble evaluation?

Thank you.

-----

Projection:

Polar stereographic. The first reference latitude is 90.0 N, the
second
reference latitude is 60.0 N, and the reference longitude is 215.0 E
(145.0 W). The map origin latitude, longitude is (60.0 N, 124.99 E).
The
equatorial radius of the map is 6,378.137 km.

Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1

Variables:

                 LAT   dimensions = (ny, nx)   type = FLOAT

The center latitude of each pixel, in units of
“degrees_north”. Positive
values indicate northern hemisphere latitudes. Missing value = -999.0

LON   dimensions = (ny, nx)    type = FLOAT

The center longitude of each pixel, in units of
“degrees_east”. Positive
values indicate eastern hemisphere longitudes and negative values
indicate western hemisphere longitudes. Missing value = -999.0

BTD1415   dimensions = (ny, nx)

The number of seconds since January 1, 1970 00:00:00 UTC for each
pixel.  Missing value  = 0

ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT

The retrieved ash mass per unit area of for each pixel identified as
ash, in units of g m-2. Missing value = -999.0



On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
> Binyu,
>
> You have 3 options:
> (1) Use MET's internal NetCDF file format.
> (2) Follow the NetCDF Climate Forecast conventions.
> (3) Use python embedding to define the projection information and
pass the
> data in memory to MET.
>
> Perhaps option (1) is most simple.  To generate an example, I used a
sample
> GFS file in GRIB format and ran MET's regrid_data_plane tool to put
it on a
> known Polar Stereographic grid.  From the list of EMC grids, I
picked grid
> number 5:
> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>
> And ran this command:
> *   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib
G005
> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>
> Then I ran plot_data_plane to make sure the result looks reasonable:
> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
> 'name="PRMSL_L0"; level="(*,*)";'*
>
> I've attached a PNG of the resulting plot and the NetCDF file
itself.  If
> you mimic this conventions of this file, it should be readable by
MET.
>
> Thanks,
> John
>
>
> On Tue, Jan 7, 2020 at 8:39 AM binyu.wang at noaa.gov via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>
>> Hello John,
>>
>> Do you have an example of the NetCDF file that can be read by MET?
Thank
>> you.
>>
>> Binyu
>>
>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
>>> Binyu,
>>>
>>> I grabbed your data and am taking a look.  I see that your NetCDF
file is
>>> on a polar stereographic projection, but I don't see the
definition of
>> that
>>> grid.  I do see the lat/lon fields but MET actually needs the
parameters
>> to
>>> define the projection itself.
>>>
>>> Any idea what those are?
>>>
>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
>>>
>>> How do you ultimately want to do the comparison?  Regrid the
forecast to
>>> the observation domain?  Or vice-versa?
>>>
>>> Either way, we do still need to know how that polar stereographic
grid is
>>> defined.
>>>
>>> Thanks,
>>> John
>>>
>>> On Mon, Jan 6, 2020 at 10:42 AM binyu.wang at noaa.gov via RT <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>>>> Transaction: Ticket created by binyu.wang at noaa.gov
>>>>          Queue: met_help
>>>>        Subject: ensemble verification with MET
>>>>          Owner: Nobody
>>>>     Requestors: binyu.wang at noaa.gov
>>>>         Status: new
>>>>    Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>>>>
>>>> Hello,
>>>>
>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use MET
>>>> for ensemble verification.
>>>>
>>>> My forecast data is under:
>>>>
>>>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>>> (and cgrib2.002, ..cgrib2.005)
>>>>
>>>> My obs. data is::
>>>>
>>>>
>>>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>>>     I am trying to evaluate "VAFTD" from forecast data versus
>>>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>>>>
>>>> 1.It seems my NetCDF can not be read by MET directly. It is
classic
>>>> format, but MET can not read it.
>>>>
>>>> 2.The unit conversion also needs to be considered: if we assume
the unit
>>>> from Forecast is F, unit from obs. is Obs, then
>>>>
>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>>>
>>>> It seems hat the input model and observation datasets needs to be
on the
>>>> same grid, How to do that?
>>>>
>>>> Thank you very much for help.
>>>>
>>>> Binyu
>>>>
>>>>
>>>>
>>

------------------------------------------------
Subject: ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Thu Jan 23 09:21:35 2020

Hello John,

How are you? I am wondering if there is any progress on this question
since it has been a while. Thank you very much.

Binyu

On 1/8/2020 3:34 PM, Binyu Wang wrote:
>
> Hello John,
>
> I got the parameters used for the projection in the NetCDF file
> (please see below). How to apply the information so MET can read the
> NetCDF for ensemble evaluation?
>
> Thank you.
>
> -----
>
> Projection:
>
> Polar stereographic. The first reference latitude is 90.0 N, the
> second reference latitude is 60.0 N, and the reference longitude is
> 215.0 E (145.0 W). The map origin latitude, longitude is (60.0 N,
> 124.99 E). The equatorial radius of the map is 6,378.137 km.
>
> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>
> Variables:
>
>                 LAT   dimensions = (ny, nx)   type = FLOAT
>
> The center latitude of each pixel, in units of
> “degrees_north”. Positive values indicate northern hemisphere
> latitudes. Missing value = -999.0
>
> LON   dimensions = (ny, nx)    type = FLOAT
>
> The center longitude of each pixel, in units of
> “degrees_east”. Positive values indicate eastern hemisphere
longitudes
> and negative values indicate western hemisphere longitudes. Missing
> value = -999.0
>
> BTD1415   dimensions = (ny, nx)
>
> The number of seconds since January 1, 1970 00:00:00 UTC for each
> pixel.  Missing value  = 0
>
> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>
> The retrieved ash mass per unit area of for each pixel identified as
> ash, in units of g m-2. Missing value = -999.0
>
>
>
> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
>> Binyu,
>>
>> You have 3 options:
>> (1) Use MET's internal NetCDF file format.
>> (2) Follow the NetCDF Climate Forecast conventions.
>> (3) Use python embedding to define the projection information and
pass the
>> data in memory to MET.
>>
>> Perhaps option (1) is most simple.  To generate an example, I used
a sample
>> GFS file in GRIB format and ran MET's regrid_data_plane tool to put
it on a
>> known Polar Stereographic grid.  From the list of EMC grids, I
picked grid
>> number 5:
>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>>
>> And ran this command:
>> *   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib
G005
>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>>
>> Then I ran plot_data_plane to make sure the result looks
reasonable:
>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
>> 'name="PRMSL_L0"; level="(*,*)";'*
>>
>> I've attached a PNG of the resulting plot and the NetCDF file
itself.  If
>> you mimic this conventions of this file, it should be readable by
MET.
>>
>> Thanks,
>> John
>>
>>
>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via
RT<met_help at ucar.edu>
>> wrote:
>>
>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678  >
>>>
>>> Hello John,
>>>
>>> Do you have an example of the NetCDF file that can be read by MET?
Thank
>>> you.
>>>
>>> Binyu
>>>
>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
>>>> Binyu,
>>>>
>>>> I grabbed your data and am taking a look.  I see that your NetCDF
file is
>>>> on a polar stereographic projection, but I don't see the
definition of
>>> that
>>>> grid.  I do see the lat/lon fields but MET actually needs the
parameters
>>> to
>>>> define the projection itself.
>>>>
>>>> Any idea what those are?
>>>>
>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
>>>>
>>>> How do you ultimately want to do the comparison?  Regrid the
forecast to
>>>> the observation domain?  Or vice-versa?
>>>>
>>>> Either way, we do still need to know how that polar stereographic
grid is
>>>> defined.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
>>>>>          Queue: met_help
>>>>>        Subject: ensemble verification with MET
>>>>>          Owner: Nobody
>>>>>     Requestors:binyu.wang at noaa.gov
>>>>>         Status: new
>>>>>    Ticket
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>>>>> Hello,
>>>>>
>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use MET
>>>>> for ensemble verification.
>>>>>
>>>>> My forecast data is under:
>>>>>
>>>>>
>>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>>>> (and cgrib2.002, ..cgrib2.005)
>>>>>
>>>>> My obs. data is::
>>>>>
>>>>>
>>>>>
>>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>>>>     I am trying to evaluate "VAFTD" from forecast data versus
>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>>>>>
>>>>> 1.It seems my NetCDF can not be read by MET directly. It is
classic
>>>>> format, but MET can not read it.
>>>>>
>>>>> 2.The unit conversion also needs to be considered: if we assume
the unit
>>>>> from Forecast is F, unit from obs. is Obs, then
>>>>>
>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>>>>
>>>>> It seems hat the input model and observation datasets needs to
be on the
>>>>> same grid, How to do that?
>>>>>
>>>>> Thank you very much for help.
>>>>>
>>>>> Binyu
>>>>>
>>>>>
>>>>>

------------------------------------------------
Subject: ensemble verification with MET
From: John Halley Gotway
Time: Thu Jan 23 09:33:28 2020

Binyu,

Apologies.  I lost track of this issue over AMS.  I see that you've
sent me
information about your projection and you're wondering how to format
this
into a NetCDF file for use by MET.

Am I correct in thinking that you want to reformat the following
NetCDF
file to make it follow the NetCDF format used by MET?

*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*

Thanks,
John

Projection:

Polar stereographic. The first reference latitude is 90.0 N, the
second
reference latitude is 60.0 N, and the reference longitude is 215.0 E
(145.0 W). The map origin latitude, longitude is (60.0 N, 124.99 E).
The
equatorial radius of the map is 6,378.137 km.

Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1

Variables:

                 LAT   dimensions = (ny, nx)   type = FLOAT

The center latitude of each pixel, in units of “degrees_north”.
Positive
values indicate northern hemisphere latitudes. Missing value = -999.0

LON   dimensions = (ny, nx)    type = FLOAT

The center longitude of each pixel, in units of “degrees_east”.
Positive
values indicate eastern hemisphere longitudes and negative values
indicate western hemisphere longitudes. Missing value = -999.0

BTD1415   dimensions = (ny, nx)

The number of seconds since January 1, 1970 00:00:00 UTC for each
pixel.  Missing value  = 0

ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT

The retrieved ash mass per unit area of for each pixel identified as
ash, in units of g m-2. Missing value = -999.0

On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>
> Hello John,
>
> How are you? I am wondering if there is any progress on this
question
> since it has been a while. Thank you very much.
>
> Binyu
>
> On 1/8/2020 3:34 PM, Binyu Wang wrote:
> >
> > Hello John,
> >
> > I got the parameters used for the projection in the NetCDF file
> > (please see below). How to apply the information so MET can read
the
> > NetCDF for ensemble evaluation?
> >
> > Thank you.
> >
> > -----
> >
> > Projection:
> >
> > Polar stereographic. The first reference latitude is 90.0 N, the
> > second reference latitude is 60.0 N, and the reference longitude
is
> > 215.0 E (145.0 W). The map origin latitude, longitude is (60.0 N,
> > 124.99 E). The equatorial radius of the map is 6,378.137 km.
> >
> > Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
> >
> > Variables:
> >
> >                 LAT   dimensions = (ny, nx)   type = FLOAT
> >
> > The center latitude of each pixel, in units of
> > “degrees_north”. Positive values indicate northern hemisphere
> > latitudes. Missing value = -999.0
> >
> > LON   dimensions = (ny, nx)    type = FLOAT
> >
> > The center longitude of each pixel, in units of
> > “degrees_east”. Positive values indicate eastern hemisphere
longitudes
> > and negative values indicate western hemisphere longitudes.
Missing
> > value = -999.0
> >
> > BTD1415   dimensions = (ny, nx)
> >
> > The number of seconds since January 1, 1970 00:00:00 UTC for each
> > pixel.  Missing value  = 0
> >
> > ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
> >
> > The retrieved ash mass per unit area of for each pixel identified
as
> > ash, in units of g m-2. Missing value = -999.0
> >
> >
> >
> > On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
> >> Binyu,
> >>
> >> You have 3 options:
> >> (1) Use MET's internal NetCDF file format.
> >> (2) Follow the NetCDF Climate Forecast conventions.
> >> (3) Use python embedding to define the projection information and
pass
> the
> >> data in memory to MET.
> >>
> >> Perhaps option (1) is most simple.  To generate an example, I
used a
> sample
> >> GFS file in GRIB format and ran MET's regrid_data_plane tool to
put it
> on a
> >> known Polar Stereographic grid.  From the list of EMC grids, I
picked
> grid
> >> number 5:
> >> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
> >>
> >> And ran this command:
> >> *   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib
G005
> >> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
> >>
> >> Then I ran plot_data_plane to make sure the result looks
reasonable:
> >> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
> >> 'name="PRMSL_L0"; level="(*,*)";'*
> >>
> >> I've attached a PNG of the resulting plot and the NetCDF file
itself.
> If
> >> you mimic this conventions of this file, it should be readable by
MET.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
> met_help at ucar.edu>
> >> wrote:
> >>
> >>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678  >
> >>>
> >>> Hello John,
> >>>
> >>> Do you have an example of the NetCDF file that can be read by
MET?
> Thank
> >>> you.
> >>>
> >>> Binyu
> >>>
> >>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> >>>> Binyu,
> >>>>
> >>>> I grabbed your data and am taking a look.  I see that your
NetCDF
> file is
> >>>> on a polar stereographic projection, but I don't see the
definition of
> >>> that
> >>>> grid.  I do see the lat/lon fields but MET actually needs the
> parameters
> >>> to
> >>>> define the projection itself.
> >>>>
> >>>> Any idea what those are?
> >>>>
> >>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
> >>>>
> >>>> How do you ultimately want to do the comparison?  Regrid the
forecast
> to
> >>>> the observation domain?  Or vice-versa?
> >>>>
> >>>> Either way, we do still need to know how that polar
stereographic
> grid is
> >>>> defined.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
> >>>> met_help at ucar.edu> wrote:
> >>>>
> >>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> >>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
> >>>>>          Queue: met_help
> >>>>>        Subject: ensemble verification with MET
> >>>>>          Owner: Nobody
> >>>>>     Requestors:binyu.wang at noaa.gov
> >>>>>         Status: new
> >>>>>    Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
> >>>>> Hello,
> >>>>>
> >>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use
> MET
> >>>>> for ensemble verification.
> >>>>>
> >>>>> My forecast data is under:
> >>>>>
> >>>>>
> >>>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
> >>>>> (and cgrib2.002, ..cgrib2.005)
> >>>>>
> >>>>> My obs. data is::
> >>>>>
> >>>>>
> >>>>>
> >>>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
> >>>>>     I am trying to evaluate "VAFTD" from forecast data versus
> >>>>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
> >>>>>
> >>>>> 1.It seems my NetCDF can not be read by MET directly. It is
classic
> >>>>> format, but MET can not read it.
> >>>>>
> >>>>> 2.The unit conversion also needs to be considered: if we
assume the
> unit
> >>>>> from Forecast is F, unit from obs. is Obs, then
> >>>>>
> >>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
> >>>>>
> >>>>> It seems hat the input model and observation datasets needs to
be on
> the
> >>>>> same grid, How to do that?
> >>>>>
> >>>>> Thank you very much for help.
> >>>>>
> >>>>> Binyu
> >>>>>
> >>>>>
> >>>>>
>
>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #93678] ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Thu Jan 23 09:34:44 2020

Yes, you are right.

Binyu

On 1/23/2020 11:33 AM, John Halley Gotway via RT wrote:
> Binyu,
>
> Apologies.  I lost track of this issue over AMS.  I see that you've
sent me
> information about your projection and you're wondering how to format
this
> into a NetCDF file for use by MET.
>
> Am I correct in thinking that you want to reformat the following
NetCDF
> file to make it follow the NetCDF format used by MET?
>
>
*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*
>
> Thanks,
> John
>
> Projection:
>
> Polar stereographic. The first reference latitude is 90.0 N, the
second
> reference latitude is 60.0 N, and the reference longitude is 215.0 E
> (145.0 W). The map origin latitude, longitude is (60.0 N, 124.99 E).
The
> equatorial radius of the map is 6,378.137 km.
>
> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>
> Variables:
>
>                   LAT   dimensions = (ny, nx)   type = FLOAT
>
> The center latitude of each pixel, in units of “degrees_north”.
Positive
> values indicate northern hemisphere latitudes. Missing value =
-999.0
>
> LON   dimensions = (ny, nx)    type = FLOAT
>
> The center longitude of each pixel, in units of “degrees_east”.
Positive
> values indicate eastern hemisphere longitudes and negative values
> indicate western hemisphere longitudes. Missing value = -999.0
>
> BTD1415   dimensions = (ny, nx)
>
> The number of seconds since January 1, 1970 00:00:00 UTC for each
> pixel.  Missing value  = 0
>
> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>
> The retrieved ash mass per unit area of for each pixel identified as
> ash, in units of g m-2. Missing value = -999.0
>
> On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>
>> Hello John,
>>
>> How are you? I am wondering if there is any progress on this
question
>> since it has been a while. Thank you very much.
>>
>> Binyu
>>
>> On 1/8/2020 3:34 PM, Binyu Wang wrote:
>>> Hello John,
>>>
>>> I got the parameters used for the projection in the NetCDF file
>>> (please see below). How to apply the information so MET can read
the
>>> NetCDF for ensemble evaluation?
>>>
>>> Thank you.
>>>
>>> -----
>>>
>>> Projection:
>>>
>>> Polar stereographic. The first reference latitude is 90.0 N, the
>>> second reference latitude is 60.0 N, and the reference longitude
is
>>> 215.0 E (145.0 W). The map origin latitude, longitude is (60.0 N,
>>> 124.99 E). The equatorial radius of the map is 6,378.137 km.
>>>
>>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>>>
>>> Variables:
>>>
>>>                  LAT   dimensions = (ny, nx)   type = FLOAT
>>>
>>> The center latitude of each pixel, in units of
>>> “degrees_north”. Positive values indicate northern hemisphere
>>> latitudes. Missing value = -999.0
>>>
>>> LON   dimensions = (ny, nx)    type = FLOAT
>>>
>>> The center longitude of each pixel, in units of
>>> “degrees_east”. Positive values indicate eastern hemisphere
longitudes
>>> and negative values indicate western hemisphere longitudes.
Missing
>>> value = -999.0
>>>
>>> BTD1415   dimensions = (ny, nx)
>>>
>>> The number of seconds since January 1, 1970 00:00:00 UTC for each
>>> pixel.  Missing value  = 0
>>>
>>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>>>
>>> The retrieved ash mass per unit area of for each pixel identified
as
>>> ash, in units of g m-2. Missing value = -999.0
>>>
>>>
>>>
>>> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
>>>> Binyu,
>>>>
>>>> You have 3 options:
>>>> (1) Use MET's internal NetCDF file format.
>>>> (2) Follow the NetCDF Climate Forecast conventions.
>>>> (3) Use python embedding to define the projection information and
pass
>> the
>>>> data in memory to MET.
>>>>
>>>> Perhaps option (1) is most simple.  To generate an example, I
used a
>> sample
>>>> GFS file in GRIB format and ran MET's regrid_data_plane tool to
put it
>> on a
>>>> known Polar Stereographic grid.  From the list of EMC grids, I
picked
>> grid
>>>> number 5:
>>>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>>>>
>>>> And ran this command:
>>>> *   met-8.1.1/bin/regrid_data_plane gfs/gfs_2012040900_F012.grib
G005
>>>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>>>>
>>>> Then I ran plot_data_plane to make sure the result looks
reasonable:
>>>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
>>>> 'name="PRMSL_L0"; level="(*,*)";'*
>>>>
>>>> I've attached a PNG of the resulting plot and the NetCDF file
itself.
>> If
>>>> you mimic this conventions of this file, it should be readable by
MET.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
>> met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678  >
>>>>>
>>>>> Hello John,
>>>>>
>>>>> Do you have an example of the NetCDF file that can be read by
MET?
>> Thank
>>>>> you.
>>>>>
>>>>> Binyu
>>>>>
>>>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
>>>>>> Binyu,
>>>>>>
>>>>>> I grabbed your data and am taking a look.  I see that your
NetCDF
>> file is
>>>>>> on a polar stereographic projection, but I don't see the
definition of
>>>>> that
>>>>>> grid.  I do see the lat/lon fields but MET actually needs the
>> parameters
>>>>> to
>>>>>> define the projection itself.
>>>>>>
>>>>>> Any idea what those are?
>>>>>>
>>>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon grid.
>>>>>>
>>>>>> How do you ultimately want to do the comparison?  Regrid the
forecast
>> to
>>>>>> the observation domain?  Or vice-versa?
>>>>>>
>>>>>> Either way, we do still need to know how that polar
stereographic
>> grid is
>>>>>> defined.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
>>>>>> met_help at ucar.edu> wrote:
>>>>>>
>>>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>>>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
>>>>>>>           Queue: met_help
>>>>>>>         Subject: ensemble verification with MET
>>>>>>>           Owner: Nobody
>>>>>>>      Requestors:binyu.wang at noaa.gov
>>>>>>>          Status: new
>>>>>>>     Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>>>>>>> Hello,
>>>>>>>
>>>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help to
use
>> MET
>>>>>>> for ensemble verification.
>>>>>>>
>>>>>>> My forecast data is under:
>>>>>>>
>>>>>>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>>>>>> (and cgrib2.002, ..cgrib2.005)
>>>>>>>
>>>>>>> My obs. data is::
>>>>>>>
>>>>>>>
>>>>>>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>>>>>>      I am trying to evaluate "VAFTD" from forecast data versus
>>>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two problems:
>>>>>>>
>>>>>>> 1.It seems my NetCDF can not be read by MET directly. It is
classic
>>>>>>> format, but MET can not read it.
>>>>>>>
>>>>>>> 2.The unit conversion also needs to be considered: if we
assume the
>> unit
>>>>>>> from Forecast is F, unit from obs. is Obs, then
>>>>>>>
>>>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>>>>>>
>>>>>>> It seems hat the input model and observation datasets needs to
be on
>> the
>>>>>>> same grid, How to do that?
>>>>>>>
>>>>>>> Thank you very much for help.
>>>>>>>
>>>>>>> Binyu
>>>>>>>
>>>>>>>
>>>>>>>
>>

------------------------------------------------
Subject: ensemble verification with MET
From: John Halley Gotway
Time: Thu Jan 23 15:40:32 2020

Binyu,

In the updated file
(Kasatochi_2008221-070500_2008221-
152000_NEW_FILE_LATLON_PROJECTION.ncdump),
you state that the projection is lat/lon, but that is not correct.
The
data is on a polar stereographic projection, not lat/lon:
* crs:grid_mapping_name = "latitude_longitude" ;*

I ran MET's regrid_data_plane tool to put a GFS field onto a Polar
Stereographic projection... using NCEP Grid #5 (
https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html).
*   regrid_data_plane gfs_2012040900_F012.grib2 G005 sample_G005.nc
-field
'name="TMP";level="Z2";'*

And I used the resulting output file as a template for what needs to
change
in your file.  Listed below is the grid nav for NCEP grid number 5.
The
only remaining info I need from your is the "d_km" setting.  That's
the
distance in km between subsequent grid points at the reference
latitude (60
N in your case).

Any idea what that spacing is for your grid?

Thanks,
John

:Projection = "Polar Stereographic" ;
:hemisphere = "N" ;
:scale_lat = "60.000000 degrees_north" ;
:lat_pin = "7.647000" ;
:lon_pin = "-133.443000" ;
:x_pin = "0.000000" ;
:y_pin = "0.000000" ;
:lon_orient = "-105.000000" ;
:d_km = "190.500000 km" ;
:r_km = "6371.200000 km" ;
:nx = "53" ;
:ny = "57" ;


On Thu, Jan 23, 2020 at 9:35 AM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>
> Yes, you are right.
>
> Binyu
>
> On 1/23/2020 11:33 AM, John Halley Gotway via RT wrote:
> > Binyu,
> >
> > Apologies.  I lost track of this issue over AMS.  I see that
you've sent
> me
> > information about your projection and you're wondering how to
format this
> > into a NetCDF file for use by MET.
> >
> > Am I correct in thinking that you want to reformat the following
NetCDF
> > file to make it follow the NetCDF format used by MET?
> >
> >
>
*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*
> >
> > Thanks,
> > John
> >
> > Projection:
> >
> > Polar stereographic. The first reference latitude is 90.0 N, the
second
> > reference latitude is 60.0 N, and the reference longitude is 215.0
E
> > (145.0 W). The map origin latitude, longitude is (60.0 N, 124.99
E). The
> > equatorial radius of the map is 6,378.137 km.
> >
> > Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
> >
> > Variables:
> >
> >                   LAT   dimensions = (ny, nx)   type = FLOAT
> >
> > The center latitude of each pixel, in units of “degrees_north”.
Positive
> > values indicate northern hemisphere latitudes. Missing value =
-999.0
> >
> > LON   dimensions = (ny, nx)    type = FLOAT
> >
> > The center longitude of each pixel, in units of “degrees_east”.
Positive
> > values indicate eastern hemisphere longitudes and negative values
> > indicate western hemisphere longitudes. Missing value = -999.0
> >
> > BTD1415   dimensions = (ny, nx)
> >
> > The number of seconds since January 1, 1970 00:00:00 UTC for each
> > pixel.  Missing value  = 0
> >
> > ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
> >
> > The retrieved ash mass per unit area of for each pixel identified
as
> > ash, in units of g m-2. Missing value = -999.0
> >
> > On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
> >>
> >> Hello John,
> >>
> >> How are you? I am wondering if there is any progress on this
question
> >> since it has been a while. Thank you very much.
> >>
> >> Binyu
> >>
> >> On 1/8/2020 3:34 PM, Binyu Wang wrote:
> >>> Hello John,
> >>>
> >>> I got the parameters used for the projection in the NetCDF file
> >>> (please see below). How to apply the information so MET can read
the
> >>> NetCDF for ensemble evaluation?
> >>>
> >>> Thank you.
> >>>
> >>> -----
> >>>
> >>> Projection:
> >>>
> >>> Polar stereographic. The first reference latitude is 90.0 N, the
> >>> second reference latitude is 60.0 N, and the reference longitude
is
> >>> 215.0 E (145.0 W). The map origin latitude, longitude is (60.0
N,
> >>> 124.99 E). The equatorial radius of the map is 6,378.137 km.
> >>>
> >>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
> >>>
> >>> Variables:
> >>>
> >>>                  LAT   dimensions = (ny, nx)   type = FLOAT
> >>>
> >>> The center latitude of each pixel, in units of
> >>> “degrees_north”. Positive values indicate northern hemisphere
> >>> latitudes. Missing value = -999.0
> >>>
> >>> LON   dimensions = (ny, nx)    type = FLOAT
> >>>
> >>> The center longitude of each pixel, in units of
> >>> “degrees_east”. Positive values indicate eastern hemisphere
longitudes
> >>> and negative values indicate western hemisphere longitudes.
Missing
> >>> value = -999.0
> >>>
> >>> BTD1415   dimensions = (ny, nx)
> >>>
> >>> The number of seconds since January 1, 1970 00:00:00 UTC for
each
> >>> pixel.  Missing value  = 0
> >>>
> >>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
> >>>
> >>> The retrieved ash mass per unit area of for each pixel
identified as
> >>> ash, in units of g m-2. Missing value = -999.0
> >>>
> >>>
> >>>
> >>> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
> >>>> Binyu,
> >>>>
> >>>> You have 3 options:
> >>>> (1) Use MET's internal NetCDF file format.
> >>>> (2) Follow the NetCDF Climate Forecast conventions.
> >>>> (3) Use python embedding to define the projection information
and pass
> >> the
> >>>> data in memory to MET.
> >>>>
> >>>> Perhaps option (1) is most simple.  To generate an example, I
used a
> >> sample
> >>>> GFS file in GRIB format and ran MET's regrid_data_plane tool to
put it
> >> on a
> >>>> known Polar Stereographic grid.  From the list of EMC grids, I
picked
> >> grid
> >>>> number 5:
> >>>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
> >>>>
> >>>> And ran this command:
> >>>> *   met-8.1.1/bin/regrid_data_plane
gfs/gfs_2012040900_F012.grib G005
> >>>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
> >>>>
> >>>> Then I ran plot_data_plane to make sure the result looks
reasonable:
> >>>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
> >>>> 'name="PRMSL_L0"; level="(*,*)";'*
> >>>>
> >>>> I've attached a PNG of the resulting plot and the NetCDF file
itself.
> >> If
> >>>> you mimic this conventions of this file, it should be readable
by MET.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
> >> met_help at ucar.edu>
> >>>> wrote:
> >>>>
> >>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>
> >>>>>
> >>>>> Hello John,
> >>>>>
> >>>>> Do you have an example of the NetCDF file that can be read by
MET?
> >> Thank
> >>>>> you.
> >>>>>
> >>>>> Binyu
> >>>>>
> >>>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> >>>>>> Binyu,
> >>>>>>
> >>>>>> I grabbed your data and am taking a look.  I see that your
NetCDF
> >> file is
> >>>>>> on a polar stereographic projection, but I don't see the
definition
> of
> >>>>> that
> >>>>>> grid.  I do see the lat/lon fields but MET actually needs the
> >> parameters
> >>>>> to
> >>>>>> define the projection itself.
> >>>>>>
> >>>>>> Any idea what those are?
> >>>>>>
> >>>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon
grid.
> >>>>>>
> >>>>>> How do you ultimately want to do the comparison?  Regrid the
> forecast
> >> to
> >>>>>> the observation domain?  Or vice-versa?
> >>>>>>
> >>>>>> Either way, we do still need to know how that polar
stereographic
> >> grid is
> >>>>>> defined.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John
> >>>>>>
> >>>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
> >>>>>> met_help at ucar.edu> wrote:
> >>>>>>
> >>>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> >>>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
> >>>>>>>           Queue: met_help
> >>>>>>>         Subject: ensemble verification with MET
> >>>>>>>           Owner: Nobody
> >>>>>>>      Requestors:binyu.wang at noaa.gov
> >>>>>>>          Status: new
> >>>>>>>     Ticket <URL:
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help
to use
> >> MET
> >>>>>>> for ensemble verification.
> >>>>>>>
> >>>>>>> My forecast data is under:
> >>>>>>>
> >>>>>>>
> >>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
> >>>>>>> (and cgrib2.002, ..cgrib2.005)
> >>>>>>>
> >>>>>>> My obs. data is::
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
> >>>>>>>      I am trying to evaluate "VAFTD" from forecast data
versus
> >>>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two
problems:
> >>>>>>>
> >>>>>>> 1.It seems my NetCDF can not be read by MET directly. It is
classic
> >>>>>>> format, but MET can not read it.
> >>>>>>>
> >>>>>>> 2.The unit conversion also needs to be considered: if we
assume the
> >> unit
> >>>>>>> from Forecast is F, unit from obs. is Obs, then
> >>>>>>>
> >>>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
> >>>>>>>
> >>>>>>> It seems hat the input model and observation datasets needs
to be
> on
> >> the
> >>>>>>> same grid, How to do that?
> >>>>>>>
> >>>>>>> Thank you very much for help.
> >>>>>>>
> >>>>>>> Binyu
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>
>
>

------------------------------------------------
Subject: ensemble verification with MET
From: John Halley Gotway
Time: Thu Jan 23 16:06:39 2020

FYI, I did some guessing and setting d_km to "7 km" produces a result
that
looks somewhat in the ballpark with the lat/lon values in the input
NetCDF
file.

So I set the projection information as:
 :MET_version = "V8.1" ;
:Projection = "Polar Stereographic" ;
:hemisphere = "N" ;
:scale_lat = "60 degrees_north" ;
:lat_pin = "60.04486" ;
:lon_pin = "125.0797" ;
:x_pin = "0.0" ;
:y_pin = "0.0" ;
:lon_orient = "-145.0" ;
:d_km = "7 km" ;
:r_km = "6371.2 km" ;
:nx = "1600" ;
:ny = "1450" ;

And I renamed the dx and dy dimensions as lon and lat, respectively.

And I added the "valid_time_ut" attribute to each variable to define
the
valid time of the data:
:valid_time_ut = "1218197389";

And I ran plot_data_plane to produce the attached result:

*plot_data_plane Kasatochi_2008221-070500_2008221-152000_MET.nc
plot.ps
<http://plot.ps> 'name="BTD1114"; level="(*,*)";'*

So you just need to figure out the correct grid spacing and decide how
you
want to assign a "Valid Time" for this data.

Thanks,
John
 Kasatochi_2008221-070500_2008221-152000.netcdf
<https://drive.google.com/a/ucar.edu/file/d/1FF3xYl3V3ecX8ga9aAHSe9f9albQ6zdR/view?usp=drive_web>
 plot.png
<https://drive.google.com/a/ucar.edu/file/d/1IEWdeec_3oaPnDGRVEHi5aGTSAA4uzON/view?usp=drive_web>


On Thu, Jan 23, 2020 at 3:40 PM John Halley Gotway <johnhg at ucar.edu>
wrote:

> Binyu,
>
> In the updated file (Kasatochi_2008221-070500_2008221-
152000_NEW_FILE_LATLON_PROJECTION.ncdump),
> you state that the projection is lat/lon, but that is not correct.
The
> data is on a polar stereographic projection, not lat/lon:
> * crs:grid_mapping_name = "latitude_longitude" ;*
>
> I ran MET's regrid_data_plane tool to put a GFS field onto a Polar
> Stereographic projection... using NCEP Grid #5 (
> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html).
> *   regrid_data_plane gfs_2012040900_F012.grib2 G005 sample_G005.nc
-field
> 'name="TMP";level="Z2";'*
>
> And I used the resulting output file as a template for what needs to
> change in your file.  Listed below is the grid nav for NCEP grid
number 5.
> The only remaining info I need from your is the "d_km" setting.
That's the
> distance in km between subsequent grid points at the reference
latitude (60
> N in your case).
>
> Any idea what that spacing is for your grid?
>
> Thanks,
> John
>
> :Projection = "Polar Stereographic" ;
> :hemisphere = "N" ;
> :scale_lat = "60.000000 degrees_north" ;
> :lat_pin = "7.647000" ;
> :lon_pin = "-133.443000" ;
> :x_pin = "0.000000" ;
> :y_pin = "0.000000" ;
> :lon_orient = "-105.000000" ;
> :d_km = "190.500000 km" ;
> :r_km = "6371.200000 km" ;
> :nx = "53" ;
> :ny = "57" ;
>
>
> On Thu, Jan 23, 2020 at 9:35 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>
>> Yes, you are right.
>>
>> Binyu
>>
>> On 1/23/2020 11:33 AM, John Halley Gotway via RT wrote:
>> > Binyu,
>> >
>> > Apologies.  I lost track of this issue over AMS.  I see that
you've
>> sent me
>> > information about your projection and you're wondering how to
format
>> this
>> > into a NetCDF file for use by MET.
>> >
>> > Am I correct in thinking that you want to reformat the following
NetCDF
>> > file to make it follow the NetCDF format used by MET?
>> >
>> >
>>
*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*
>> >
>> > Thanks,
>> > John
>> >
>> > Projection:
>> >
>> > Polar stereographic. The first reference latitude is 90.0 N, the
second
>> > reference latitude is 60.0 N, and the reference longitude is
215.0 E
>> > (145.0 W). The map origin latitude, longitude is (60.0 N, 124.99
E). The
>> > equatorial radius of the map is 6,378.137 km.
>> >
>> > Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>> >
>> > Variables:
>> >
>> >                   LAT   dimensions = (ny, nx)   type = FLOAT
>> >
>> > The center latitude of each pixel, in units of “degrees_north”.
Positive
>> > values indicate northern hemisphere latitudes. Missing value =
-999.0
>> >
>> > LON   dimensions = (ny, nx)    type = FLOAT
>> >
>> > The center longitude of each pixel, in units of “degrees_east”.
Positive
>> > values indicate eastern hemisphere longitudes and negative values
>> > indicate western hemisphere longitudes. Missing value = -999.0
>> >
>> > BTD1415   dimensions = (ny, nx)
>> >
>> > The number of seconds since January 1, 1970 00:00:00 UTC for each
>> > pixel.  Missing value  = 0
>> >
>> > ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>> >
>> > The retrieved ash mass per unit area of for each pixel identified
as
>> > ash, in units of g m-2. Missing value = -999.0
>> >
>> > On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>> >>
>> >> Hello John,
>> >>
>> >> How are you? I am wondering if there is any progress on this
question
>> >> since it has been a while. Thank you very much.
>> >>
>> >> Binyu
>> >>
>> >> On 1/8/2020 3:34 PM, Binyu Wang wrote:
>> >>> Hello John,
>> >>>
>> >>> I got the parameters used for the projection in the NetCDF file
>> >>> (please see below). How to apply the information so MET can
read the
>> >>> NetCDF for ensemble evaluation?
>> >>>
>> >>> Thank you.
>> >>>
>> >>> -----
>> >>>
>> >>> Projection:
>> >>>
>> >>> Polar stereographic. The first reference latitude is 90.0 N,
the
>> >>> second reference latitude is 60.0 N, and the reference
longitude is
>> >>> 215.0 E (145.0 W). The map origin latitude, longitude is (60.0
N,
>> >>> 124.99 E). The equatorial radius of the map is 6,378.137 km.
>> >>>
>> >>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>> >>>
>> >>> Variables:
>> >>>
>> >>>                  LAT   dimensions = (ny, nx)   type = FLOAT
>> >>>
>> >>> The center latitude of each pixel, in units of
>> >>> “degrees_north”. Positive values indicate northern hemisphere
>> >>> latitudes. Missing value = -999.0
>> >>>
>> >>> LON   dimensions = (ny, nx)    type = FLOAT
>> >>>
>> >>> The center longitude of each pixel, in units of
>> >>> “degrees_east”. Positive values indicate eastern hemisphere
longitudes
>> >>> and negative values indicate western hemisphere longitudes.
Missing
>> >>> value = -999.0
>> >>>
>> >>> BTD1415   dimensions = (ny, nx)
>> >>>
>> >>> The number of seconds since January 1, 1970 00:00:00 UTC for
each
>> >>> pixel.  Missing value  = 0
>> >>>
>> >>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>> >>>
>> >>> The retrieved ash mass per unit area of for each pixel
identified as
>> >>> ash, in units of g m-2. Missing value = -999.0
>> >>>
>> >>>
>> >>>
>> >>> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
>> >>>> Binyu,
>> >>>>
>> >>>> You have 3 options:
>> >>>> (1) Use MET's internal NetCDF file format.
>> >>>> (2) Follow the NetCDF Climate Forecast conventions.
>> >>>> (3) Use python embedding to define the projection information
and
>> pass
>> >> the
>> >>>> data in memory to MET.
>> >>>>
>> >>>> Perhaps option (1) is most simple.  To generate an example, I
used a
>> >> sample
>> >>>> GFS file in GRIB format and ran MET's regrid_data_plane tool
to put
>> it
>> >> on a
>> >>>> known Polar Stereographic grid.  From the list of EMC grids, I
picked
>> >> grid
>> >>>> number 5:
>> >>>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>> >>>>
>> >>>> And ran this command:
>> >>>> *   met-8.1.1/bin/regrid_data_plane
gfs/gfs_2012040900_F012.grib G005
>> >>>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>> >>>>
>> >>>> Then I ran plot_data_plane to make sure the result looks
reasonable:
>> >>>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
>> >>>> 'name="PRMSL_L0"; level="(*,*)";'*
>> >>>>
>> >>>> I've attached a PNG of the resulting plot and the NetCDF file
itself.
>> >> If
>> >>>> you mimic this conventions of this file, it should be readable
by
>> MET.
>> >>>>
>> >>>> Thanks,
>> >>>> John
>> >>>>
>> >>>>
>> >>>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
>> >> met_help at ucar.edu>
>> >>>> wrote:
>> >>>>
>> >>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>
>> >>>>>
>> >>>>> Hello John,
>> >>>>>
>> >>>>> Do you have an example of the NetCDF file that can be read by
MET?
>> >> Thank
>> >>>>> you.
>> >>>>>
>> >>>>> Binyu
>> >>>>>
>> >>>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
>> >>>>>> Binyu,
>> >>>>>>
>> >>>>>> I grabbed your data and am taking a look.  I see that your
NetCDF
>> >> file is
>> >>>>>> on a polar stereographic projection, but I don't see the
>> definition of
>> >>>>> that
>> >>>>>> grid.  I do see the lat/lon fields but MET actually needs
the
>> >> parameters
>> >>>>> to
>> >>>>>> define the projection itself.
>> >>>>>>
>> >>>>>> Any idea what those are?
>> >>>>>>
>> >>>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon
grid.
>> >>>>>>
>> >>>>>> How do you ultimately want to do the comparison?  Regrid the
>> forecast
>> >> to
>> >>>>>> the observation domain?  Or vice-versa?
>> >>>>>>
>> >>>>>> Either way, we do still need to know how that polar
stereographic
>> >> grid is
>> >>>>>> defined.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> John
>> >>>>>>
>> >>>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
>> >>>>>> met_help at ucar.edu> wrote:
>> >>>>>>
>> >>>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>> >>>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
>> >>>>>>>           Queue: met_help
>> >>>>>>>         Subject: ensemble verification with MET
>> >>>>>>>           Owner: Nobody
>> >>>>>>>      Requestors:binyu.wang at noaa.gov
>> >>>>>>>          Status: new
>> >>>>>>>     Ticket <URL:
>> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>> >>>>>>> Hello,
>> >>>>>>>
>> >>>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help
to use
>> >> MET
>> >>>>>>> for ensemble verification.
>> >>>>>>>
>> >>>>>>> My forecast data is under:
>> >>>>>>>
>> >>>>>>>
>> >>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>> >>>>>>> (and cgrib2.002, ..cgrib2.005)
>> >>>>>>>
>> >>>>>>> My obs. data is::
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>> >>>>>>>      I am trying to evaluate "VAFTD" from forecast data
versus
>> >>>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two
problems:
>> >>>>>>>
>> >>>>>>> 1.It seems my NetCDF can not be read by MET directly. It is
>> classic
>> >>>>>>> format, but MET can not read it.
>> >>>>>>>
>> >>>>>>> 2.The unit conversion also needs to be considered: if we
assume
>> the
>> >> unit
>> >>>>>>> from Forecast is F, unit from obs. is Obs, then
>> >>>>>>>
>> >>>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>> >>>>>>>
>> >>>>>>> It seems hat the input model and observation datasets needs
to be
>> on
>> >> the
>> >>>>>>> same grid, How to do that?
>> >>>>>>>
>> >>>>>>> Thank you very much for help.
>> >>>>>>>
>> >>>>>>> Binyu
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>
>>
>>

------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #93678] ensemble verification with MET
From: binyu.wang at noaa.gov
Time: Fri Jan 24 08:32:51 2020

Hello John,

Thank you so much!

I don't have permission to access the google plot, can you provide the
permission?

Two more question here:

1. How do you set the projection information? Use python to add the
attributes to each file or MET has any internal utility to do that?

2. About the "valid time": how do yo define that? Just give the time
when valid data is monitored?

By the way, the d_km is 4.2km

Have a great weekend.

Binyu

On 1/23/2020 6:06 PM, John Halley Gotway via RT wrote:
> FYI, I did some guessing and setting d_km to "7 km" produces a
result that
> looks somewhat in the ballpark with the lat/lon values in the input
NetCDF
> file.
>
> So I set the projection information as:
>   :MET_version = "V8.1" ;
> :Projection = "Polar Stereographic" ;
> :hemisphere = "N" ;
> :scale_lat = "60 degrees_north" ;
> :lat_pin = "60.04486" ;
> :lon_pin = "125.0797" ;
> :x_pin = "0.0" ;
> :y_pin = "0.0" ;
> :lon_orient = "-145.0" ;
> :d_km = "7 km" ;
> :r_km = "6371.2 km" ;
> :nx = "1600" ;
> :ny = "1450" ;
>
> And I renamed the dx and dy dimensions as lon and lat, respectively.
>
> And I added the "valid_time_ut" attribute to each variable to define
the
> valid time of the data:
> :valid_time_ut = "1218197389";
>
> And I ran plot_data_plane to produce the attached result:
>
> *plot_data_plane Kasatochi_2008221-070500_2008221-152000_MET.nc
plot.ps
> <http://plot.ps> 'name="BTD1114"; level="(*,*)";'*
>
> So you just need to figure out the correct grid spacing and decide
how you
> want to assign a "Valid Time" for this data.
>
> Thanks,
> John
>   Kasatochi_2008221-070500_2008221-152000.netcdf
>
<https://drive.google.com/a/ucar.edu/file/d/1FF3xYl3V3ecX8ga9aAHSe9f9albQ6zdR/view?usp=drive_web>
>   plot.png
>
<https://drive.google.com/a/ucar.edu/file/d/1IEWdeec_3oaPnDGRVEHi5aGTSAA4uzON/view?usp=drive_web>
>
>
> On Thu, Jan 23, 2020 at 3:40 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
>
>> Binyu,
>>
>> In the updated file (Kasatochi_2008221-070500_2008221-
152000_NEW_FILE_LATLON_PROJECTION.ncdump),
>> you state that the projection is lat/lon, but that is not correct.
The
>> data is on a polar stereographic projection, not lat/lon:
>> * crs:grid_mapping_name = "latitude_longitude" ;*
>>
>> I ran MET's regrid_data_plane tool to put a GFS field onto a Polar
>> Stereographic projection... using NCEP Grid #5 (
>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html).
>> *   regrid_data_plane gfs_2012040900_F012.grib2 G005 sample_G005.nc
-field
>> 'name="TMP";level="Z2";'*
>>
>> And I used the resulting output file as a template for what needs
to
>> change in your file.  Listed below is the grid nav for NCEP grid
number 5.
>> The only remaining info I need from your is the "d_km" setting.
That's the
>> distance in km between subsequent grid points at the reference
latitude (60
>> N in your case).
>>
>> Any idea what that spacing is for your grid?
>>
>> Thanks,
>> John
>>
>> :Projection = "Polar Stereographic" ;
>> :hemisphere = "N" ;
>> :scale_lat = "60.000000 degrees_north" ;
>> :lat_pin = "7.647000" ;
>> :lon_pin = "-133.443000" ;
>> :x_pin = "0.000000" ;
>> :y_pin = "0.000000" ;
>> :lon_orient = "-105.000000" ;
>> :d_km = "190.500000 km" ;
>> :r_km = "6371.200000 km" ;
>> :nx = "53" ;
>> :ny = "57" ;
>>
>>
>> On Thu, Jan 23, 2020 at 9:35 AM binyu.wang at noaa.gov via RT <
>> met_help at ucar.edu> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>>
>>> Yes, you are right.
>>>
>>> Binyu
>>>
>>> On 1/23/2020 11:33 AM, John Halley Gotway via RT wrote:
>>>> Binyu,
>>>>
>>>> Apologies.  I lost track of this issue over AMS.  I see that
you've
>>> sent me
>>>> information about your projection and you're wondering how to
format
>>> this
>>>> into a NetCDF file for use by MET.
>>>>
>>>> Am I correct in thinking that you want to reformat the following
NetCDF
>>>> file to make it follow the NetCDF format used by MET?
>>>>
>>>>
>>>
*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*
>>>> Thanks,
>>>> John
>>>>
>>>> Projection:
>>>>
>>>> Polar stereographic. The first reference latitude is 90.0 N, the
second
>>>> reference latitude is 60.0 N, and the reference longitude is
215.0 E
>>>> (145.0 W). The map origin latitude, longitude is (60.0 N, 124.99
E). The
>>>> equatorial radius of the map is 6,378.137 km.
>>>>
>>>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>>>>
>>>> Variables:
>>>>
>>>>                    LAT   dimensions = (ny, nx)   type = FLOAT
>>>>
>>>> The center latitude of each pixel, in units of “degrees_north”.
Positive
>>>> values indicate northern hemisphere latitudes. Missing value =
-999.0
>>>>
>>>> LON   dimensions = (ny, nx)    type = FLOAT
>>>>
>>>> The center longitude of each pixel, in units of “degrees_east”.
Positive
>>>> values indicate eastern hemisphere longitudes and negative values
>>>> indicate western hemisphere longitudes. Missing value = -999.0
>>>>
>>>> BTD1415   dimensions = (ny, nx)
>>>>
>>>> The number of seconds since January 1, 1970 00:00:00 UTC for each
>>>> pixel.  Missing value  = 0
>>>>
>>>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>>>>
>>>> The retrieved ash mass per unit area of for each pixel identified
as
>>>> ash, in units of g m-2. Missing value = -999.0
>>>>
>>>> On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>>>>>
>>>>> Hello John,
>>>>>
>>>>> How are you? I am wondering if there is any progress on this
question
>>>>> since it has been a while. Thank you very much.
>>>>>
>>>>> Binyu
>>>>>
>>>>> On 1/8/2020 3:34 PM, Binyu Wang wrote:
>>>>>> Hello John,
>>>>>>
>>>>>> I got the parameters used for the projection in the NetCDF file
>>>>>> (please see below). How to apply the information so MET can
read the
>>>>>> NetCDF for ensemble evaluation?
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> -----
>>>>>>
>>>>>> Projection:
>>>>>>
>>>>>> Polar stereographic. The first reference latitude is 90.0 N,
the
>>>>>> second reference latitude is 60.0 N, and the reference
longitude is
>>>>>> 215.0 E (145.0 W). The map origin latitude, longitude is (60.0
N,
>>>>>> 124.99 E). The equatorial radius of the map is 6,378.137 km.
>>>>>>
>>>>>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
>>>>>>
>>>>>> Variables:
>>>>>>
>>>>>>                   LAT   dimensions = (ny, nx)   type = FLOAT
>>>>>>
>>>>>> The center latitude of each pixel, in units of
>>>>>> “degrees_north”. Positive values indicate northern hemisphere
>>>>>> latitudes. Missing value = -999.0
>>>>>>
>>>>>> LON   dimensions = (ny, nx)    type = FLOAT
>>>>>>
>>>>>> The center longitude of each pixel, in units of
>>>>>> “degrees_east”. Positive values indicate eastern hemisphere
longitudes
>>>>>> and negative values indicate western hemisphere longitudes.
Missing
>>>>>> value = -999.0
>>>>>>
>>>>>> BTD1415   dimensions = (ny, nx)
>>>>>>
>>>>>> The number of seconds since January 1, 1970 00:00:00 UTC for
each
>>>>>> pixel.  Missing value  = 0
>>>>>>
>>>>>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
>>>>>>
>>>>>> The retrieved ash mass per unit area of for each pixel
identified as
>>>>>> ash, in units of g m-2. Missing value = -999.0
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
>>>>>>> Binyu,
>>>>>>>
>>>>>>> You have 3 options:
>>>>>>> (1) Use MET's internal NetCDF file format.
>>>>>>> (2) Follow the NetCDF Climate Forecast conventions.
>>>>>>> (3) Use python embedding to define the projection information
and
>>> pass
>>>>> the
>>>>>>> data in memory to MET.
>>>>>>>
>>>>>>> Perhaps option (1) is most simple.  To generate an example, I
used a
>>>>> sample
>>>>>>> GFS file in GRIB format and ran MET's regrid_data_plane tool
to put
>>> it
>>>>> on a
>>>>>>> known Polar Stereographic grid.  From the list of EMC grids, I
picked
>>>>> grid
>>>>>>> number 5:
>>>>>>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>>>>>>>
>>>>>>> And ran this command:
>>>>>>> *   met-8.1.1/bin/regrid_data_plane
gfs/gfs_2012040900_F012.grib G005
>>>>>>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
>>>>>>>
>>>>>>> Then I ran plot_data_plane to make sure the result looks
reasonable:
>>>>>>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
>>>>>>> 'name="PRMSL_L0"; level="(*,*)";'*
>>>>>>>
>>>>>>> I've attached a PNG of the resulting plot and the NetCDF file
itself.
>>>>> If
>>>>>>> you mimic this conventions of this file, it should be readable
by
>>> MET.
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
>>>>> met_help at ucar.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> <URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>
>>>>>>>>
>>>>>>>> Hello John,
>>>>>>>>
>>>>>>>> Do you have an example of the NetCDF file that can be read by
MET?
>>>>> Thank
>>>>>>>> you.
>>>>>>>>
>>>>>>>> Binyu
>>>>>>>>
>>>>>>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
>>>>>>>>> Binyu,
>>>>>>>>>
>>>>>>>>> I grabbed your data and am taking a look.  I see that your
NetCDF
>>>>> file is
>>>>>>>>> on a polar stereographic projection, but I don't see the
>>> definition of
>>>>>>>> that
>>>>>>>>> grid.  I do see the lat/lon fields but MET actually needs
the
>>>>> parameters
>>>>>>>> to
>>>>>>>>> define the projection itself.
>>>>>>>>>
>>>>>>>>> Any idea what those are?
>>>>>>>>>
>>>>>>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon
grid.
>>>>>>>>>
>>>>>>>>> How do you ultimately want to do the comparison?  Regrid the
>>> forecast
>>>>> to
>>>>>>>>> the observation domain?  Or vice-versa?
>>>>>>>>>
>>>>>>>>> Either way, we do still need to know how that polar
stereographic
>>>>> grid is
>>>>>>>>> defined.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT <
>>>>>>>>> met_help at ucar.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
>>>>>>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
>>>>>>>>>>            Queue: met_help
>>>>>>>>>>          Subject: ensemble verification with MET
>>>>>>>>>>            Owner: Nobody
>>>>>>>>>>       Requestors:binyu.wang at noaa.gov
>>>>>>>>>>           Status: new
>>>>>>>>>>      Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need help
to use
>>>>> MET
>>>>>>>>>> for ensemble verification.
>>>>>>>>>>
>>>>>>>>>> My forecast data is under:
>>>>>>>>>>
>>>>>>>>>>
>>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
>>>>>>>>>> (and cgrib2.002, ..cgrib2.005)
>>>>>>>>>>
>>>>>>>>>> My obs. data is::
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
>>>>>>>>>>       I am trying to evaluate "VAFTD" from forecast data
versus
>>>>>>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two
problems:
>>>>>>>>>>
>>>>>>>>>> 1.It seems my NetCDF can not be read by MET directly. It is
>>> classic
>>>>>>>>>> format, but MET can not read it.
>>>>>>>>>>
>>>>>>>>>> 2.The unit conversion also needs to be considered: if we
assume
>>> the
>>>>> unit
>>>>>>>>>> from Forecast is F, unit from obs. is Obs, then
>>>>>>>>>>
>>>>>>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
>>>>>>>>>>
>>>>>>>>>> It seems hat the input model and observation datasets needs
to be
>>> on
>>>>> the
>>>>>>>>>> same grid, How to do that?
>>>>>>>>>>
>>>>>>>>>> Thank you very much for help.
>>>>>>>>>>
>>>>>>>>>> Binyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>

------------------------------------------------
Subject: ensemble verification with MET
From: John Halley Gotway
Time: Fri Jan 24 09:15:29 2020

Binyu,

OK, using d_km = 4.2km results in the attached plot.  As for how to
edit
the NetCDF file, it's really up to you.  Since this file is being
created
from multiple Aqua input files, I would just edit whatever script is
creating the to modify the output format.  For my own testing, I used
"ncdump" to dump the file to ascii.  Then I edited the ascii file
(adding
projection info, renaming dimensions, and adding the valid_time_ut
variable
attribute).  And I ran "ncgen" to regenerate the modified NetCDF file.

ncdump Kasatochi_2008221-070500_2008221-152000.netcdf >
Kasatochi_2008221-070500_2008221-152000.ncdump
# Edit the ncdump file
ncgen Kasatochi_2008221-070500_2008221-152000.ncdump
-o Kasatochi_2008221-070500_2008221-152000_MET.nc

One could also use NCO tools to modify the format:
*ncrename* to change dimension names.
*ncatted* to add global projection attributes and add the
valid_time_ut
variable attributes.

But if you can, just edit whatever script is writing this file in the
first
place to modify the format there.

Below I've listed the header for the final NetCDF file.

Thanks,
John

[johnhg at number5]% ncdump -h Kasatochi_2008221-070500_2008221-
152000_MET.nc
netcdf Kasatochi_2008221-070500_2008221-152000_MET {
dimensions:
       lon = 1600 ;
       lat = 1450 ;
       single = 1 ;
variables:
       float LAT(lat, lon) ;
               LAT:units = "degrees_north" ;
               LAT:long_name = "Latitude" ;
               LAT:missing_value = -999.f ;
       float LON(lat, lon) ;
               LON:units = "degrees_east" ;
               LON:long_name = "Longitude" ;
               LON:missing_value = -999.f ;
       float BTD1415(lat, lon) ;
               BTD1415:units = "degrees Kelvin" ;
               BTD1415:long_name = "Brightness Temperature Difference
(11um-12um)" ;
               BTD1415:missing_value = -999.f ;
               BTD1415:valid_time_ut = "1218197389" ;
       float BTD714(lat, lon) ;
               BTD714:units = "degrees Kelvin" ;
               BTD714:long_name = "Brightness Temperature Difference
(3.9um-11um)" ;
               BTD714:missing_value = -999.f ;
               BTD714:valid_time_ut = "1218197389" ;
       float BTD1114(lat, lon) ;
               BTD1114:units = "degrees Kelvin" ;
               BTD1114:long_name = "Brightness Temperature Difference
(8.5um-11um)" ;
               BTD1114:missing_value = -999.f ;
               BTD1114:valid_time_ut = "1218197389" ;
       float BT14(lat, lon) ;
               BT14:units = "degrees Kelvin" ;
               BT14:long_name = "Brightness Temperature (11um)" ;
               BT14:missing_value = -999.f ;
               BT14:valid_time_ut = "1218197389" ;
       float REF2(lat, lon) ;
               REF2:units = "dimensionless" ;
               REF2:long_name = "Visible Reflectance (0.65um)" ;
               REF2:missing_value = -999.f ;
               REF2:valid_time_ut = "1218197389" ;
       int PIXEL_TIME(lat, lon) ;
               PIXEL_TIME:units = "seconds since 1970-01-01 00:00" ;
               PIXEL_TIME:missing_value = 0 ;
               PIXEL_TIME:long_name = "Time of MODIS pixel
observation" ;
       float ASH_PROBABILITY(lat, lon) ;
               ASH_PROBABILITY:units = "dimensionless" ;
               ASH_PROBABILITY:long_name = "Probability pixel contains
volcanic ash" ;
               ASH_PROBABILITY:missing_value = -999.f ;
       float ASH_HEIGHT(lat, lon) ;
               ASH_HEIGHT:units = "km ASL" ;
               ASH_HEIGHT:long_name = "Retrieved ash cloud top height"
;
               ASH_HEIGHT:missing_value = -999.f ;
               ASH_HEIGHT:valid_time_ut = "1218197389" ;
       float ASH_MASS_LOADING(lat, lon) ;
               ASH_MASS_LOADING:units = "g/m^2" ;
               ASH_MASS_LOADING:long_name = "Retrieved column ash mass
loading" ;
               ASH_MASS_LOADING:missing_value = -999.f ;
               ASH_MASS_LOADING:valid_time_ut = "1218197389" ;
       float ASH_EFFECTIVE_RADIUS(lat, lon) ;
               ASH_EFFECTIVE_RADIUS:units = "micron" ;
               ASH_EFFECTIVE_RADIUS:long_name = "Retrieved ash
effective
radius" ;
               ASH_EFFECTIVE_RADIUS:missing_value = -999.f ;
               ASH_EFFECTIVE_RADIUS:valid_time_ut = "1218197389" ;
       int T0(single) ;
               T0:units = "seconds since 1970-01-01 00:00" ;
               T0:long_name = "Approx start time of eruptive event of
interest" ;
       int T(single) ;
               T:units = "seconds since 1970-01-01 00:00" ;
               T:long_name = "Start time of MODIS overpass containing
ash"
;
       float TDIFF_HRS(single) ;
               TDIFF_HRS:units = "hours" ;
               TDIFF_HRS:long_name = "Hours since start of eruptive
event
at 0445 UTC Aug 8,2008" ;
       int DAY(single) ;
               DAY:units = "day of month" ;
               DAY:long_name = "Day of Month (Aug. 2008)" ;
       float TOTAL_AREA(single) ;
               TOTAL_AREA:units = "km^2" ;
               TOTAL_AREA:long_name = "Total area of entire ash cloud"
;
       float TOTAL_MASS(single) ;
               TOTAL_MASS:units = "Tg" ;
               TOTAL_MASS:long_name = "Total mass of entire ash cloud"
;
       float LOADING25(single) ;
               LOADING25:units = "g/m^2" ;
               LOADING25:long_name = "25th percentile pixel mass
loading" ;
       float LOADING50(single) ;
               LOADING50:units = "g/m^2" ;
               LOADING50:long_name = "50th percentile pixel mass
loading" ;
       float LOADING75(single) ;
               LOADING75:units = "g/m^2" ;
               LOADING75:long_name = "75th percentile pixel mass
loading" ;
       float REFF25(single) ;
               REFF25:units = "micron" ;
               REFF25:long_name = "25th percentile pixel effective
radius"
;
       float REFF50(single) ;
               REFF50:units = "micron" ;
               REFF50:long_name = "50th percentile pixel effective
radius"
;
       float REFF75(single) ;
               REFF75:units = "micron" ;
               REFF75:long_name = "75th percentile pixel effective
radius"
;
       float HEIGHT25(single) ;
               HEIGHT25:units = "km ASL" ;
               HEIGHT25:long_name = "25th percentile pixel height" ;
       float HEIGHT50(single) ;
               HEIGHT50:units = "km ASL" ;
               HEIGHT50:long_name = "50th percentile pixel height" ;
       float HEIGHT75(single) ;
               HEIGHT75:units = "km ASL" ;
               HEIGHT75:long_name = "75th percentile pixel height" ;

// global attributes:
               :valid_time_ut = "1218197389" ;
               :Composite_members =
"geocatL2.Aqua.2008221.070500.hdf,geocatL2.Aqua.2008221.083500.hdf,geocatL2.Aqua.2008221.084000.hdf,geocatL2.Aqua.2008221.084500.hdf,geoca
tL2.Aqua.2008221.101500.hdf,geocatL2.Aqua.2008221.102000.hdf,geocatL2.Aqua.2008221.102500.hdf,geocatL2.Aqua.2008221.115500.hdf,geocatL2.Aqua.2008221.120000.hdf,geocatL2.Aqua.2
008221.120500.hdf,geocatL2.Aqua.2008221.133500.hdf,geocatL2.Aqua.2008221.134000.hdf,geocatL2.Aqua.2008221.134500.hdf,geocatL2.Aqua.2008221.151000.hdf,geocatL2.Aqua.2008221.151
500.hdf,geocatL2.Aqua.2008221.152000.hdf" ;
               :First_time = "2008221-070500" ;
               :Last_time = "2008221-152000" ;
               :MET_version = "V9.0" ;
               :Projection = "Polar Stereographic" ;
               :hemisphere = "N" ;
               :scale_lat = "60 degrees_north" ;
               :lat_pin = "60.04486" ;
               :lon_pin = "125.0797" ;
               :x_pin = "0.0" ;
               :y_pin = "0.0" ;
               :lon_orient = "-145.0" ;
               :d_km = "4.2 km" ;
               :r_km = "6371.2 km" ;
               :nx = "1600" ;
               :ny = "1450" ;
}



On Fri, Jan 24, 2020 at 8:33 AM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:

>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
>
> Hello John,
>
> Thank you so much!
>
> I don't have permission to access the google plot, can you provide
the
> permission?
>
> Two more question here:
>
> 1. How do you set the projection information? Use python to add the
> attributes to each file or MET has any internal utility to do that?
>
> 2. About the "valid time": how do yo define that? Just give the time
> when valid data is monitored?
>
> By the way, the d_km is 4.2km
>
> Have a great weekend.
>
> Binyu
>
> On 1/23/2020 6:06 PM, John Halley Gotway via RT wrote:
> > FYI, I did some guessing and setting d_km to "7 km" produces a
result
> that
> > looks somewhat in the ballpark with the lat/lon values in the
input
> NetCDF
> > file.
> >
> > So I set the projection information as:
> >   :MET_version = "V8.1" ;
> > :Projection = "Polar Stereographic" ;
> > :hemisphere = "N" ;
> > :scale_lat = "60 degrees_north" ;
> > :lat_pin = "60.04486" ;
> > :lon_pin = "125.0797" ;
> > :x_pin = "0.0" ;
> > :y_pin = "0.0" ;
> > :lon_orient = "-145.0" ;
> > :d_km = "7 km" ;
> > :r_km = "6371.2 km" ;
> > :nx = "1600" ;
> > :ny = "1450" ;
> >
> > And I renamed the dx and dy dimensions as lon and lat,
respectively.
> >
> > And I added the "valid_time_ut" attribute to each variable to
define the
> > valid time of the data:
> > :valid_time_ut = "1218197389";
> >
> > And I ran plot_data_plane to produce the attached result:
> >
> > *plot_data_plane Kasatochi_2008221-070500_2008221-152000_MET.nc
plot.ps
> > <http://plot.ps> 'name="BTD1114"; level="(*,*)";'*
> >
> > So you just need to figure out the correct grid spacing and decide
how
> you
> > want to assign a "Valid Time" for this data.
> >
> > Thanks,
> > John
> >   Kasatochi_2008221-070500_2008221-152000.netcdf
> > <
>
https://drive.google.com/a/ucar.edu/file/d/1FF3xYl3V3ecX8ga9aAHSe9f9albQ6zdR/view?usp=drive_web
> >
> >   plot.png
> > <
>
https://drive.google.com/a/ucar.edu/file/d/1IEWdeec_3oaPnDGRVEHi5aGTSAA4uzON/view?usp=drive_web
> >
> >
> >
> > On Thu, Jan 23, 2020 at 3:40 PM John Halley Gotway
<johnhg at ucar.edu>
> wrote:
> >
> >> Binyu,
> >>
> >> In the updated file
> (Kasatochi_2008221-070500_2008221-
152000_NEW_FILE_LATLON_PROJECTION.ncdump),
> >> you state that the projection is lat/lon, but that is not
correct.  The
> >> data is on a polar stereographic projection, not lat/lon:
> >> * crs:grid_mapping_name = "latitude_longitude" ;*
> >>
> >> I ran MET's regrid_data_plane tool to put a GFS field onto a
Polar
> >> Stereographic projection... using NCEP Grid #5 (
> >> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html).
> >> *   regrid_data_plane gfs_2012040900_F012.grib2 G005
sample_G005.nc
> -field
> >> 'name="TMP";level="Z2";'*
> >>
> >> And I used the resulting output file as a template for what needs
to
> >> change in your file.  Listed below is the grid nav for NCEP grid
number
> 5.
> >> The only remaining info I need from your is the "d_km" setting.
That's
> the
> >> distance in km between subsequent grid points at the reference
latitude
> (60
> >> N in your case).
> >>
> >> Any idea what that spacing is for your grid?
> >>
> >> Thanks,
> >> John
> >>
> >> :Projection = "Polar Stereographic" ;
> >> :hemisphere = "N" ;
> >> :scale_lat = "60.000000 degrees_north" ;
> >> :lat_pin = "7.647000" ;
> >> :lon_pin = "-133.443000" ;
> >> :x_pin = "0.000000" ;
> >> :y_pin = "0.000000" ;
> >> :lon_orient = "-105.000000" ;
> >> :d_km = "190.500000 km" ;
> >> :r_km = "6371.200000 km" ;
> >> :nx = "53" ;
> >> :ny = "57" ;
> >>
> >>
> >> On Thu, Jan 23, 2020 at 9:35 AM binyu.wang at noaa.gov via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678 >
> >>>
> >>> Yes, you are right.
> >>>
> >>> Binyu
> >>>
> >>> On 1/23/2020 11:33 AM, John Halley Gotway via RT wrote:
> >>>> Binyu,
> >>>>
> >>>> Apologies.  I lost track of this issue over AMS.  I see that
you've
> >>> sent me
> >>>> information about your projection and you're wondering how to
format
> >>> this
> >>>> into a NetCDF file for use by MET.
> >>>>
> >>>> Am I correct in thinking that you want to reformat the
following
> NetCDF
> >>>> file to make it follow the NetCDF format used by MET?
> >>>>
> >>>>
> >>>
>
*/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf*
> >>>> Thanks,
> >>>> John
> >>>>
> >>>> Projection:
> >>>>
> >>>> Polar stereographic. The first reference latitude is 90.0 N,
the
> second
> >>>> reference latitude is 60.0 N, and the reference longitude is
215.0 E
> >>>> (145.0 W). The map origin latitude, longitude is (60.0 N,
124.99 E).
> The
> >>>> equatorial radius of the map is 6,378.137 km.
> >>>>
> >>>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
> >>>>
> >>>> Variables:
> >>>>
> >>>>                    LAT   dimensions = (ny, nx)   type = FLOAT
> >>>>
> >>>> The center latitude of each pixel, in units of “degrees_north”.
> Positive
> >>>> values indicate northern hemisphere latitudes. Missing value =
-999.0
> >>>>
> >>>> LON   dimensions = (ny, nx)    type = FLOAT
> >>>>
> >>>> The center longitude of each pixel, in units of “degrees_east”.
> Positive
> >>>> values indicate eastern hemisphere longitudes and negative
values
> >>>> indicate western hemisphere longitudes. Missing value = -999.0
> >>>>
> >>>> BTD1415   dimensions = (ny, nx)
> >>>>
> >>>> The number of seconds since January 1, 1970 00:00:00 UTC for
each
> >>>> pixel.  Missing value  = 0
> >>>>
> >>>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
> >>>>
> >>>> The retrieved ash mass per unit area of for each pixel
identified as
> >>>> ash, in units of g m-2. Missing value = -999.0
> >>>>
> >>>> On Thu, Jan 23, 2020 at 9:22 AM binyu.wang at noaa.gov via RT <
> >>>> met_help at ucar.edu> wrote:
> >>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
>
> >>>>>
> >>>>> Hello John,
> >>>>>
> >>>>> How are you? I am wondering if there is any progress on this
question
> >>>>> since it has been a while. Thank you very much.
> >>>>>
> >>>>> Binyu
> >>>>>
> >>>>> On 1/8/2020 3:34 PM, Binyu Wang wrote:
> >>>>>> Hello John,
> >>>>>>
> >>>>>> I got the parameters used for the projection in the NetCDF
file
> >>>>>> (please see below). How to apply the information so MET can
read the
> >>>>>> NetCDF for ensemble evaluation?
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>> -----
> >>>>>>
> >>>>>> Projection:
> >>>>>>
> >>>>>> Polar stereographic. The first reference latitude is 90.0 N,
the
> >>>>>> second reference latitude is 60.0 N, and the reference
longitude is
> >>>>>> 215.0 E (145.0 W). The map origin latitude, longitude is
(60.0 N,
> >>>>>> 124.99 E). The equatorial radius of the map is 6,378.137 km.
> >>>>>>
> >>>>>> Dimensions:  ny= 1450 ;  nx = 1600 ;  single = 1
> >>>>>>
> >>>>>> Variables:
> >>>>>>
> >>>>>>                   LAT   dimensions = (ny, nx)   type = FLOAT
> >>>>>>
> >>>>>> The center latitude of each pixel, in units of
> >>>>>> “degrees_north”. Positive values indicate northern hemisphere
> >>>>>> latitudes. Missing value = -999.0
> >>>>>>
> >>>>>> LON   dimensions = (ny, nx)    type = FLOAT
> >>>>>>
> >>>>>> The center longitude of each pixel, in units of
> >>>>>> “degrees_east”. Positive values indicate eastern hemisphere
> longitudes
> >>>>>> and negative values indicate western hemisphere longitudes.
Missing
> >>>>>> value = -999.0
> >>>>>>
> >>>>>> BTD1415   dimensions = (ny, nx)
> >>>>>>
> >>>>>> The number of seconds since January 1, 1970 00:00:00 UTC for
each
> >>>>>> pixel.  Missing value  = 0
> >>>>>>
> >>>>>> ASH_MASS_LOADING   dimensions = (ny, nx)    type = FLOAT
> >>>>>>
> >>>>>> The retrieved ash mass per unit area of for each pixel
identified as
> >>>>>> ash, in units of g m-2. Missing value = -999.0
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/7/2020 11:46 AM, John Halley Gotway via RT wrote:
> >>>>>>> Binyu,
> >>>>>>>
> >>>>>>> You have 3 options:
> >>>>>>> (1) Use MET's internal NetCDF file format.
> >>>>>>> (2) Follow the NetCDF Climate Forecast conventions.
> >>>>>>> (3) Use python embedding to define the projection
information and
> >>> pass
> >>>>> the
> >>>>>>> data in memory to MET.
> >>>>>>>
> >>>>>>> Perhaps option (1) is most simple.  To generate an example,
I used
> a
> >>>>> sample
> >>>>>>> GFS file in GRIB format and ran MET's regrid_data_plane tool
to put
> >>> it
> >>>>> on a
> >>>>>>> known Polar Stereographic grid.  From the list of EMC grids,
I
> picked
> >>>>> grid
> >>>>>>> number 5:
> >>>>>>> https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
> >>>>>>>
> >>>>>>> And ran this command:
> >>>>>>> *   met-8.1.1/bin/regrid_data_plane
gfs/gfs_2012040900_F012.grib
> G005
> >>>>>>> gfs_G005.nc -field 'name="PRMSL"; level="L0";'*
> >>>>>>>
> >>>>>>> Then I ran plot_data_plane to make sure the result looks
> reasonable:
> >>>>>>> *    met-8.1.1/bin/plot_data_plane gfs_G005.nc gfs_G005.ps
> >>>>>>> 'name="PRMSL_L0"; level="(*,*)";'*
> >>>>>>>
> >>>>>>> I've attached a PNG of the resulting plot and the NetCDF
file
> itself.
> >>>>> If
> >>>>>>> you mimic this conventions of this file, it should be
readable by
> >>> MET.
> >>>>>>> Thanks,
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Jan 7, 2020 at 8:39 AMbinyu.wang at noaa.gov  via RT<
> >>>>> met_help at ucar.edu>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
<URL:https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678  >
> >>>>>>>>
> >>>>>>>> Hello John,
> >>>>>>>>
> >>>>>>>> Do you have an example of the NetCDF file that can be read
by MET?
> >>>>> Thank
> >>>>>>>> you.
> >>>>>>>>
> >>>>>>>> Binyu
> >>>>>>>>
> >>>>>>>> On 1/6/2020 6:03 PM, John Halley Gotway via RT wrote:
> >>>>>>>>> Binyu,
> >>>>>>>>>
> >>>>>>>>> I grabbed your data and am taking a look.  I see that your
NetCDF
> >>>>> file is
> >>>>>>>>> on a polar stereographic projection, but I don't see the
> >>> definition of
> >>>>>>>> that
> >>>>>>>>> grid.  I do see the lat/lon fields but MET actually needs
the
> >>>>> parameters
> >>>>>>>> to
> >>>>>>>>> define the projection itself.
> >>>>>>>>>
> >>>>>>>>> Any idea what those are?
> >>>>>>>>>
> >>>>>>>>> Is see that your GRIB2 output is on a 0.1 degree lat/lon
grid.
> >>>>>>>>>
> >>>>>>>>> How do you ultimately want to do the comparison?  Regrid
the
> >>> forecast
> >>>>> to
> >>>>>>>>> the observation domain?  Or vice-versa?
> >>>>>>>>>
> >>>>>>>>> Either way, we do still need to know how that polar
stereographic
> >>>>> grid is
> >>>>>>>>> defined.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> John
> >>>>>>>>>
> >>>>>>>>> On Mon, Jan 6, 2020 at 10:42 AMbinyu.wang at noaa.gov  via RT
<
> >>>>>>>>> met_help at ucar.edu> wrote:
> >>>>>>>>>
> >>>>>>>>>> Mon Jan 06 10:42:45 2020: Request 93678 was acted upon.
> >>>>>>>>>> Transaction: Ticket created bybinyu.wang at noaa.gov
> >>>>>>>>>>            Queue: met_help
> >>>>>>>>>>          Subject: ensemble verification with MET
> >>>>>>>>>>            Owner: Nobody
> >>>>>>>>>>       Requestors:binyu.wang at noaa.gov
> >>>>>>>>>>           Status: new
> >>>>>>>>>>      Ticket <URL:
> >>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93678
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> Happy New Year. This is Binyu from NCEP/EMC and I need
help to
> use
> >>>>> MET
> >>>>>>>>>> for ensemble verification.
> >>>>>>>>>>
> >>>>>>>>>> My forecast data is under:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3_0.1_0.1/cgrib2.001
> >>>>>>>>>> (and cgrib2.002, ..cgrib2.005)
> >>>>>>>>>>
> >>>>>>>>>> My obs. data is::
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Kasatochi/Obs/Kasatochi_2008221-
070500_2008221-152000.netcdf
> >>>>>>>>>>       I am trying to evaluate "VAFTD" from forecast data
versus
> >>>>>>>>>> "ASH_MASS_LOADING" in the obs. files.  There are two
problems:
> >>>>>>>>>>
> >>>>>>>>>> 1.It seems my NetCDF can not be read by MET directly. It
is
> >>> classic
> >>>>>>>>>> format, but MET can not read it.
> >>>>>>>>>>
> >>>>>>>>>> 2.The unit conversion also needs to be considered: if we
assume
> >>> the
> >>>>> unit
> >>>>>>>>>> from Forecast is F, unit from obs. is Obs, then
> >>>>>>>>>>
> >>>>>>>>>> Obs=(10^F)*2500*3600*(10^3)*(2000/2)^(1/0.241)
> >>>>>>>>>>
> >>>>>>>>>> It seems hat the input model and observation datasets
needs to
> be
> >>> on
> >>>>> the
> >>>>>>>>>> same grid, How to do that?
> >>>>>>>>>>
> >>>>>>>>>> Thank you very much for help.
> >>>>>>>>>>
> >>>>>>>>>> Binyu
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
>
>

------------------------------------------------


More information about the Met_help mailing list