[Met_help] [rt.rap.ucar.edu #81014] History for evaluation of mean sea level pressure
John Halley Gotway via RT
met_help at ucar.edu
Mon Aug 28 09:17:53 MDT 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Dear met help,
I am wondering how to evaluate mean sea level pressure. In the fcst section of the PointStatConfig settings, I insert
field = [
{
name = "PRMSL";
level = [ "???" ];
},
but what to put for level? What is the correct level for sea level? Would P1013 be correct? I could not find anything on this in the documentation, sorry.
Thanks for any help on this, Cheers,
Jonas Berndt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Mon Jun 26 13:29:17 2017
Hello Jonas,
I see you have a question about configuring the level setting in the
Point-Stat config file. Since you're using "PRMSL", I assume you're
passing GRIB data to the Point-Stat tool.
When I'm trying to figure out the name or level value, I use the
plot_data_plane utility instead of Point-Stat. Plot-Data-Plane simply
reads the requested 2D field from a gridded data file and makes a plot
of
it.
Let's say you're input file is named "model.grib", please try:
met-6.0/bin/plot_data_plane model.grib prmsl.ps 'name="PRMSL";
level="L0";'
The level value in your GRIB data file is likely zero... so saying
"L0" or
"Z0" would both probably work.
Assuming plot_data_plane runs fine, display the resulting PostScript
image
to make sure that MET is plotting your data at the expected location
on
earth.
Hope that helps.
Thanks,
John Halley Gotway
On Mon, Jun 26, 2017 at 12:53 PM, Jonas Berndt via RT
<met_help at ucar.edu>
wrote:
>
> Mon Jun 26 12:53:37 2017: Request 81014 was acted upon.
> Transaction: Ticket created by j.berndt at fz-juelich.de
> Queue: met_help
> Subject: evaluation of mean sea level pressure
> Owner: Nobody
> Requestors: j.berndt at fz-juelich.de
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>
>
> Dear met help,
>
> I am wondering how to evaluate mean sea level pressure. In the fcst
> section of the PointStatConfig settings, I insert
>
> field = [
> {
> name = "PRMSL";
> level = [ "???" ];
>
> },
>
> but what to put for level? What is the correct level for sea level?
Would
> P1013 be correct? I could not find anything on this in the
documentation,
> sorry.
>
> Thanks for any help on this, Cheers,
>
> Jonas Berndt
>
>
> ------------------------------------------------------------
> ------------------------------------
> ------------------------------------------------------------
> ------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
> ------------------------------------------------------------
> ------------------------------------
> ------------------------------------------------------------
> ------------------------------------
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #81014] evaluation of mean sea level pressure
From: Jonas Berndt
Time: Thu Jun 29 09:24:19 2017
Hello John,
yes correct, I am passing GRIB data to the Point-Stat tool. With "Z0"
I
got the correct model values for "PRMSL".
Still I was confused about the naming since "Z0" should be at the
surface, so would rather fit to "PSFC"...
But thanks a lot for your prompt answer on this, Cheers,
Jonas
On 06/26/2017 09:29 PM, John Halley Gotway via RT wrote:
> Hello Jonas,
>
> I see you have a question about configuring the level setting in the
> Point-Stat config file. Since you're using "PRMSL", I assume you're
> passing GRIB data to the Point-Stat tool.
>
> When I'm trying to figure out the name or level value, I use the
> plot_data_plane utility instead of Point-Stat. Plot-Data-Plane
simply
> reads the requested 2D field from a gridded data file and makes a
plot of
> it.
>
> Let's say you're input file is named "model.grib", please try:
> met-6.0/bin/plot_data_plane model.grib prmsl.ps 'name="PRMSL";
> level="L0";'
>
> The level value in your GRIB data file is likely zero... so saying
"L0" or
> "Z0" would both probably work.
>
> Assuming plot_data_plane runs fine, display the resulting PostScript
image
> to make sure that MET is plotting your data at the expected location
on
> earth.
>
> Hope that helps.
>
> Thanks,
> John Halley Gotway
>
> On Mon, Jun 26, 2017 at 12:53 PM, Jonas Berndt via RT
<met_help at ucar.edu>
> wrote:
>
>> Mon Jun 26 12:53:37 2017: Request 81014 was acted upon.
>> Transaction: Ticket created by j.berndt at fz-juelich.de
>> Queue: met_help
>> Subject: evaluation of mean sea level pressure
>> Owner: Nobody
>> Requestors: j.berndt at fz-juelich.de
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>
>>
>> Dear met help,
>>
>> I am wondering how to evaluate mean sea level pressure. In the fcst
>> section of the PointStatConfig settings, I insert
>>
>> field = [
>> {
>> name = "PRMSL";
>> level = [ "???" ];
>>
>> },
>>
>> but what to put for level? What is the correct level for sea level?
Would
>> P1013 be correct? I could not find anything on this in the
documentation,
>> sorry.
>>
>> Thanks for any help on this, Cheers,
>>
>> Jonas Berndt
>>
>>
>> ------------------------------------------------------------
>> ------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------
>> ------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------
>>
>>
>>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Thu Jun 29 10:32:34 2017
Jonas,
Great, glad it worked.
The "P" prefix means that you're asking for a "pressure" level. Each
GRIB
record is encoded with a particular level type, and here's a
description of
the GRIB1 level types:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html
MET contains a grouping of these level types. For example, level
types of
100 and 101 (and some others) are considered pressure level types.
Level
type 102 is for mean sea level. And I'm guessing that's how PRMSL is
encoded.
Level type 102 is considered in MET as a "vertical level type"... with
a
height value of 0... and that's why we use "Z0".
If it's more clear to you, you can use alternative config file
settings.
Instead of: level = [ "Z0" ];
You could use:
GRIB_lvl_typ = 102;
GRIB_lvl_val1 = 0;
This is mentioned in met-6.0/data/config/README.
Thanks,
John
On Thu, Jun 29, 2017 at 9:24 AM, Jonas Berndt via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>
> Hello John,
>
> yes correct, I am passing GRIB data to the Point-Stat tool. With
"Z0" I
> got the correct model values for "PRMSL".
> Still I was confused about the naming since "Z0" should be at the
> surface, so would rather fit to "PSFC"...
>
> But thanks a lot for your prompt answer on this, Cheers,
>
> Jonas
>
>
> On 06/26/2017 09:29 PM, John Halley Gotway via RT wrote:
> > Hello Jonas,
> >
> > I see you have a question about configuring the level setting in
the
> > Point-Stat config file. Since you're using "PRMSL", I assume
you're
> > passing GRIB data to the Point-Stat tool.
> >
> > When I'm trying to figure out the name or level value, I use the
> > plot_data_plane utility instead of Point-Stat. Plot-Data-Plane
simply
> > reads the requested 2D field from a gridded data file and makes a
plot of
> > it.
> >
> > Let's say you're input file is named "model.grib", please try:
> > met-6.0/bin/plot_data_plane model.grib prmsl.ps 'name="PRMSL";
> > level="L0";'
> >
> > The level value in your GRIB data file is likely zero... so saying
"L0"
> or
> > "Z0" would both probably work.
> >
> > Assuming plot_data_plane runs fine, display the resulting
PostScript
> image
> > to make sure that MET is plotting your data at the expected
location on
> > earth.
> >
> > Hope that helps.
> >
> > Thanks,
> > John Halley Gotway
> >
> > On Mon, Jun 26, 2017 at 12:53 PM, Jonas Berndt via RT
<met_help at ucar.edu
> >
> > wrote:
> >
> >> Mon Jun 26 12:53:37 2017: Request 81014 was acted upon.
> >> Transaction: Ticket created by j.berndt at fz-juelich.de
> >> Queue: met_help
> >> Subject: evaluation of mean sea level pressure
> >> Owner: Nobody
> >> Requestors: j.berndt at fz-juelich.de
> >> Status: new
> >> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014
> >
> >>
> >>
> >> Dear met help,
> >>
> >> I am wondering how to evaluate mean sea level pressure. In the
fcst
> >> section of the PointStatConfig settings, I insert
> >>
> >> field = [
> >> {
> >> name = "PRMSL";
> >> level = [ "???" ];
> >>
> >> },
> >>
> >> but what to put for level? What is the correct level for sea
level?
> Would
> >> P1013 be correct? I could not find anything on this in the
> documentation,
> >> sorry.
> >>
> >> Thanks for any help on this, Cheers,
> >>
> >> Jonas Berndt
> >>
> >>
> >> ------------------------------------------------------------
> >> ------------------------------------
> >> ------------------------------------------------------------
> >> ------------------------------------
> >> Forschungszentrum Juelich GmbH
> >> 52425 Juelich
> >> Sitz der Gesellschaft: Juelich
> >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
> >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
> >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
> >> Prof. Dr. Sebastian M. Schmidt
> >> ------------------------------------------------------------
> >> ------------------------------------
> >> ------------------------------------------------------------
> >> ------------------------------------
> >>
> >>
> >>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #81014] evaluation of mean sea level pressure
From: Jonas Berndt
Time: Sat Jul 01 06:58:37 2017
Hello John,
sorry to come back to you with those trivial questions. Thanks for
your
answer, the principle is clear to me now, you explained it well.
But what if I want to compare surface pressure from point observations
to the model? It appears to me that there
are in principle no observations of such at e.g. SYNOP stations,
solely
pressure reduced to mean sea level. Why not?
Why is then the station pressure not used as an observation? Is this
because it is just not representative due to different
elevations?
Thank you very much for any kind of help, lots of appreciation,
Jonas
On 06/29/2017 06:32 PM, John Halley Gotway via RT wrote:
> Jonas,
>
> Great, glad it worked.
>
> The "P" prefix means that you're asking for a "pressure" level.
Each GRIB
> record is encoded with a particular level type, and here's a
description of
> the GRIB1 level types:
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html
>
> MET contains a grouping of these level types. For example, level
types of
> 100 and 101 (and some others) are considered pressure level types.
Level
> type 102 is for mean sea level. And I'm guessing that's how PRMSL
is
> encoded.
>
> Level type 102 is considered in MET as a "vertical level type"...
with a
> height value of 0... and that's why we use "Z0".
>
> If it's more clear to you, you can use alternative config file
settings.
>
> Instead of: level = [ "Z0" ];
>
> You could use:
> GRIB_lvl_typ = 102;
> GRIB_lvl_val1 = 0;
>
> This is mentioned in met-6.0/data/config/README.
>
> Thanks,
> John
>
> On Thu, Jun 29, 2017 at 9:24 AM, Jonas Berndt via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>
>> Hello John,
>>
>> yes correct, I am passing GRIB data to the Point-Stat tool. With
"Z0" I
>> got the correct model values for "PRMSL".
>> Still I was confused about the naming since "Z0" should be at the
>> surface, so would rather fit to "PSFC"...
>>
>> But thanks a lot for your prompt answer on this, Cheers,
>>
>> Jonas
>>
>>
>> On 06/26/2017 09:29 PM, John Halley Gotway via RT wrote:
>>> Hello Jonas,
>>>
>>> I see you have a question about configuring the level setting in
the
>>> Point-Stat config file. Since you're using "PRMSL", I assume
you're
>>> passing GRIB data to the Point-Stat tool.
>>>
>>> When I'm trying to figure out the name or level value, I use the
>>> plot_data_plane utility instead of Point-Stat. Plot-Data-Plane
simply
>>> reads the requested 2D field from a gridded data file and makes a
plot of
>>> it.
>>>
>>> Let's say you're input file is named "model.grib", please try:
>>> met-6.0/bin/plot_data_plane model.grib prmsl.ps
'name="PRMSL";
>>> level="L0";'
>>>
>>> The level value in your GRIB data file is likely zero... so saying
"L0"
>> or
>>> "Z0" would both probably work.
>>>
>>> Assuming plot_data_plane runs fine, display the resulting
PostScript
>> image
>>> to make sure that MET is plotting your data at the expected
location on
>>> earth.
>>>
>>> Hope that helps.
>>>
>>> Thanks,
>>> John Halley Gotway
>>>
>>> On Mon, Jun 26, 2017 at 12:53 PM, Jonas Berndt via RT
<met_help at ucar.edu
>>>
>>> wrote:
>>>
>>>> Mon Jun 26 12:53:37 2017: Request 81014 was acted upon.
>>>> Transaction: Ticket created by j.berndt at fz-juelich.de
>>>> Queue: met_help
>>>> Subject: evaluation of mean sea level pressure
>>>> Owner: Nobody
>>>> Requestors: j.berndt at fz-juelich.de
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014
>>>>
>>>> Dear met help,
>>>>
>>>> I am wondering how to evaluate mean sea level pressure. In the
fcst
>>>> section of the PointStatConfig settings, I insert
>>>>
>>>> field = [
>>>> {
>>>> name = "PRMSL";
>>>> level = [ "???" ];
>>>>
>>>> },
>>>>
>>>> but what to put for level? What is the correct level for sea
level?
>> Would
>>>> P1013 be correct? I could not find anything on this in the
>> documentation,
>>>> sorry.
>>>>
>>>> Thanks for any help on this, Cheers,
>>>>
>>>> Jonas Berndt
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------------------------
>>>> ------------------------------------------------------------
>>>> ------------------------------------
>>>> Forschungszentrum Juelich GmbH
>>>> 52425 Juelich
>>>> Sitz der Gesellschaft: Juelich
>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>>>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
>>>> Prof. Dr. Sebastian M. Schmidt
>>>> ------------------------------------------------------------
>>>> ------------------------------------
>>>> ------------------------------------------------------------
>>>> ------------------------------------
>>>>
>>>>
>>>>
>>
>>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Mon Jul 03 10:14:43 2017
Jonas,
I see that you want to verify forecasts of PRMSL against point
observations. PRMSL is an observation type that can be derived by the
PB2NC tool. You just need to request it in the PB2NC config file.
Take a look at the description of the obs_grib_code entry for PB2NC on
page
77 of the MET User's Guide:
http://www.dtcenter.org/met/users/docs/users_guide/MET_Users_Guide_v6.0.pdf
Using the sample data that's distributed with the MET tarball, I did
the
following:
(1) Edit the PB2NC Config file used by the MET test scripts:
cd met-6.0/scripts
Edit config/PB2NCConfig_G212 by setting:
obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
"DPT", "WIND", "RH", "MIXR", "PRMSL" ];
(2) Rerun the PB2NC test:
rm pb2nc; make pb2nc
(3) Run the plot_point_obs tool to visualize the PRMSL locations
(PRMSL is
GRIB code 2):
../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc 2
(4) I converted the resulting PostScript image to PNG and attached it.
You'll just need to configure PB2NC to dump out PRMSL observations,
and
then you'll have them available for the verification step done in
Point-Stat. Regarding that step, configure Point-Stat to verify
against
surface observations (message_type ADPSFC), water surface observations
(message_type SFCSHP), or both combined (message_type ONLYSF). This
is
mentioned on page 110 of the user's guide.
Hope that helps get you going.
Thanks,
John
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: Jonas Berndt
Time: Thu Jul 06 07:55:48 2017
Hello John,
thanks as always for your comprehensive answer, though I am sorry if I
was not clear enough in my question. I want to compare the model to
surface pressure, not to pressure reduced to mean sea level.
Surface pressure is not treated as an observation (there is not a
particluar GIRB code), but still one has pressure measurements at the
surface (e.g. from SYNOP stations). Why aren't they treated as
observations to compare to model values? At least this is done in
assimilation systems. So why is surface pressure not included in the
MET tool? Since surface pressure is not a derived value like PRMSL, it
should be more meaningful especially at high elevations where PRMSL
approximations show quite some errors.
Thanks a lot,
Jonas
On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
Jonas,
I see that you want to verify forecasts of PRMSL against point
observations. PRMSL is an observation type that can be derived by the
PB2NC tool. You just need to request it in the PB2NC config file.
Take a look at the description of the obs_grib_code entry for PB2NC on
page
77 of the MET User's Guide:
http://www.dtcenter.org/met/users/docs/users_guide/MET_Users_Guide_v6.0.pdf
Using the sample data that's distributed with the MET tarball, I did
the
following:
(1) Edit the PB2NC Config file used by the MET test scripts:
cd met-6.0/scripts
Edit config/PB2NCConfig_G212 by setting:
obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
"DPT", "WIND", "RH", "MIXR", "PRMSL" ];
(2) Rerun the PB2NC test:
rm pb2nc; make pb2nc
(3) Run the plot_point_obs tool to visualize the PRMSL locations
(PRMSL is
GRIB code 2):
../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc 2
(4) I converted the resulting PostScript image to PNG and attached it.
You'll just need to configure PB2NC to dump out PRMSL observations,
and
then you'll have them available for the verification step done in
Point-Stat. Regarding that step, configure Point-Stat to verify
against
surface observations (message_type ADPSFC), water surface observations
(message_type SFCSHP), or both combined (message_type ONLYSF). This
is
mentioned on page 110 of the user's guide.
Hope that helps get you going.
Thanks,
John
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Thu Jul 06 08:39:18 2017
Hello Jonas,
I'm out of the office today, but will take a closer look tomorrow.
Thanks
John
On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>
> Hello John,
>
> thanks as always for your comprehensive answer, though I am sorry if
I was
> not clear enough in my question. I want to compare the model to
surface
> pressure, not to pressure reduced to mean sea level.
>
> Surface pressure is not treated as an observation (there is not a
> particluar GIRB code), but still one has pressure measurements at
the
> surface (e.g. from SYNOP stations). Why aren't they treated as
observations
> to compare to model values? At least this is done in assimilation
systems.
> So why is surface pressure not included in the MET tool? Since
surface
> pressure is not a derived value like PRMSL, it should be more
meaningful
> especially at high elevations where PRMSL approximations show quite
some
> errors.
>
> Thanks a lot,
> Jonas
>
>
>
> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
>
> Jonas,
>
> I see that you want to verify forecasts of PRMSL against point
> observations. PRMSL is an observation type that can be derived by
the
> PB2NC tool. You just need to request it in the PB2NC config file.
>
> Take a look at the description of the obs_grib_code entry for PB2NC
on page
> 77 of the MET User's Guide:
>
http://www.dtcenter.org/met/users/docs/users_guide/MET_Users_Guide_v6.0.pdf
>
> Using the sample data that's distributed with the MET tarball, I did
the
> following:
>
> (1) Edit the PB2NC Config file used by the MET test scripts:
> cd met-6.0/scripts
> Edit config/PB2NCConfig_G212 by setting:
>
> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
>
> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
>
> (2) Rerun the PB2NC test:
>
> rm pb2nc; make pb2nc
> (3) Run the plot_point_obs tool to visualize the PRMSL locations
(PRMSL is
> GRIB code 2):
> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc 2
>
> (4) I converted the resulting PostScript image to PNG and attached
it.
>
> You'll just need to configure PB2NC to dump out PRMSL observations,
and
> then you'll have them available for the verification step done in
> Point-Stat. Regarding that step, configure Point-Stat to verify
against
> surface observations (message_type ADPSFC), water surface
observations
> (message_type SFCSHP), or both combined (message_type ONLYSF). This
is
> mentioned on page 110 of the user's guide.
>
> Hope that helps get you going.
>
> Thanks,
> John
>
>
>
>
>
>
>
------------------------------------------------------------------------------------------------
>
>
------------------------------------------------------------------------------------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
>
>
------------------------------------------------------------------------------------------------
>
>
------------------------------------------------------------------------------------------------
>
>
>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Fri Jul 07 10:01:11 2017
Jonas,
OK, I'm pretty sure that MET can already do what you'd like it to do.
The GRIB code abbreviation for pressure is PRES and is GRIB code #1.
All
you need to do is request "PRES" in the obs_grib_code configuration
entry
in the PB2NC tool. That tells PB2NC to write out pressure as an
observation type.
Next, you need to configure Point-Stat to do verification at the
surface.
The handling of "surface" observations is done in a rather simplistic
way.
It's basically done by the message type. Message types of ADPSFC and
SFCSHP are assumed to be at the surface... or you can specify ONLYSF
to
group those two types together.
Just configured Point-Stat to verifying pressure against one of those
surface message types.
Please let me know how it goes. If you run into issues, I could work
up a
more detailed example for you to demonstrate it.
Thanks,
John
On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Hello Jonas,
>
> I'm out of the office today, but will take a closer look tomorrow.
>
> Thanks
> John
>
> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>
>> Hello John,
>>
>> thanks as always for your comprehensive answer, though I am sorry
if I
>> was not clear enough in my question. I want to compare the model to
surface
>> pressure, not to pressure reduced to mean sea level.
>>
>> Surface pressure is not treated as an observation (there is not a
>> particluar GIRB code), but still one has pressure measurements at
the
>> surface (e.g. from SYNOP stations). Why aren't they treated as
observations
>> to compare to model values? At least this is done in assimilation
systems.
>> So why is surface pressure not included in the MET tool? Since
surface
>> pressure is not a derived value like PRMSL, it should be more
meaningful
>> especially at high elevations where PRMSL approximations show quite
some
>> errors.
>>
>> Thanks a lot,
>> Jonas
>>
>>
>>
>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
>>
>> Jonas,
>>
>> I see that you want to verify forecasts of PRMSL against point
>> observations. PRMSL is an observation type that can be derived by
the
>> PB2NC tool. You just need to request it in the PB2NC config file.
>>
>> Take a look at the description of the obs_grib_code entry for PB2NC
on
>> page
>> 77 of the MET User's Guide:
>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
>> Users_Guide_v6.0.pdf
>>
>> Using the sample data that's distributed with the MET tarball, I
did the
>> following:
>>
>> (1) Edit the PB2NC Config file used by the MET test scripts:
>> cd met-6.0/scripts
>> Edit config/PB2NCConfig_G212 by setting:
>>
>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
>>
>> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
>>
>> (2) Rerun the PB2NC test:
>>
>> rm pb2nc; make pb2nc
>> (3) Run the plot_point_obs tool to visualize the PRMSL locations
(PRMSL is
>> GRIB code 2):
>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc 2
>>
>> (4) I converted the resulting PostScript image to PNG and attached
it.
>>
>> You'll just need to configure PB2NC to dump out PRMSL observations,
and
>> then you'll have them available for the verification step done in
>> Point-Stat. Regarding that step, configure Point-Stat to verify
against
>> surface observations (message_type ADPSFC), water surface
observations
>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This is
>> mentioned on page 110 of the user's guide.
>>
>> Hope that helps get you going.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------
>> ------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------
>>
>>
>>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: Jonas Berndt
Time: Wed Aug 02 06:50:37 2017
Hello John,
sorry for the late answer on this due to days off. I really appreciate
your prompt answers on my questions, it helps our research her very
much. This time I have even three issues which help on would be highly
appreciated.
_1. Concerning: the issue of comparing station pressure to model
data:_
The problem was indeed in the first place, that pressure was not
defined
as an observation. I always downloaded the subsets that already
ran through the PB2NC tool for NCEP assimilation. Now, I run through
PB2NC as you have told me and this works.
Nevertheless, I could not find matching pairs of observations and
model
data for station pressure. I expect the observations of station
pressure
to be at height Z2.
I am using the Unified Postprocessor to process WRF data, but even
though I request SHELTER PRESSURE, it is not included in the GRIB
files.
Obviously, UPP is not deriving this value. I.e. there is no model data
of pressure at height Z2. Only surface pressure is included which
corresponds to height L1, but this in not the case for observations. I
could upload my GRIB and observation file on our ftp if this helps?
2. _Representativity of surface observations_
I have a question on representativity of observations. It seems to me
that there is no check in the MET tool whether observations and
gridpoint match certain criteria of geographical equality. Is this
true?
E.g. I use a 12 km grid and observations and nearest grid point may be
off more than 500 meters in height (close to mountains). Or e.g. it
might be interesting to include solely surface observations with a
terrain height of e.g. below 150 meters (as it is done in some data
assimilation schemes for wind). Does MET provide some flags for
checking
this?
3. _Upper air observations (ADPUPA)_
I want to compare upper air observations from radiosondes. MET does
not
find any pairs. I attached the PointStatConfig file. Do you see
anything
suspicious? I ensured that ADPUPA observations are in the observation
file. I checked this with the plot_point_obs tool. I also set the
obs_window correct to include such observations.
Thanks a lot John for any kind of help on this,
Jonas
On 07/07/2017 06:01 PM, John Halley Gotway via RT wrote:
> Jonas,
>
> OK, I'm pretty sure that MET can already do what you'd like it to
do.
>
> The GRIB code abbreviation for pressure is PRES and is GRIB code #1.
All
> you need to do is request "PRES" in the obs_grib_code configuration
entry
> in the PB2NC tool. That tells PB2NC to write out pressure as an
> observation type.
>
> Next, you need to configure Point-Stat to do verification at the
surface.
>
> The handling of "surface" observations is done in a rather
simplistic way.
> It's basically done by the message type. Message types of ADPSFC
and
> SFCSHP are assumed to be at the surface... or you can specify ONLYSF
to
> group those two types together.
>
> Just configured Point-Stat to verifying pressure against one of
those
> surface message types.
>
> Please let me know how it goes. If you run into issues, I could
work up a
> more detailed example for you to demonstrate it.
>
> Thanks,
> John
>
> On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway <johnhg at ucar.edu>
wrote:
>
>> Hello Jonas,
>>
>> I'm out of the office today, but will take a closer look tomorrow.
>>
>> Thanks
>> John
>>
>> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>>
>>> Hello John,
>>>
>>> thanks as always for your comprehensive answer, though I am sorry
if I
>>> was not clear enough in my question. I want to compare the model
to surface
>>> pressure, not to pressure reduced to mean sea level.
>>>
>>> Surface pressure is not treated as an observation (there is not a
>>> particluar GIRB code), but still one has pressure measurements at
the
>>> surface (e.g. from SYNOP stations). Why aren't they treated as
observations
>>> to compare to model values? At least this is done in assimilation
systems.
>>> So why is surface pressure not included in the MET tool? Since
surface
>>> pressure is not a derived value like PRMSL, it should be more
meaningful
>>> especially at high elevations where PRMSL approximations show
quite some
>>> errors.
>>>
>>> Thanks a lot,
>>> Jonas
>>>
>>>
>>>
>>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
>>>
>>> Jonas,
>>>
>>> I see that you want to verify forecasts of PRMSL against point
>>> observations. PRMSL is an observation type that can be derived by
the
>>> PB2NC tool. You just need to request it in the PB2NC config file.
>>>
>>> Take a look at the description of the obs_grib_code entry for
PB2NC on
>>> page
>>> 77 of the MET User's Guide:
>>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
>>> Users_Guide_v6.0.pdf
>>>
>>> Using the sample data that's distributed with the MET tarball, I
did the
>>> following:
>>>
>>> (1) Edit the PB2NC Config file used by the MET test scripts:
>>> cd met-6.0/scripts
>>> Edit config/PB2NCConfig_G212 by setting:
>>>
>>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
>>>
>>> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
>>>
>>> (2) Rerun the PB2NC test:
>>>
>>> rm pb2nc; make pb2nc
>>> (3) Run the plot_point_obs tool to visualize the PRMSL locations
(PRMSL is
>>> GRIB code 2):
>>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc 2
>>>
>>> (4) I converted the resulting PostScript image to PNG and attached
it.
>>>
>>> You'll just need to configure PB2NC to dump out PRMSL
observations, and
>>> then you'll have them available for the verification step done in
>>> Point-Stat. Regarding that step, configure Point-Stat to verify
against
>>> surface observations (message_type ADPSFC), water surface
observations
>>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This is
>>> mentioned on page 110 of the user's guide.
>>>
>>> Hope that helps get you going.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------------------------
>>> ------------------------------------------------------------
>>> ------------------------------------
>>> Forschungszentrum Juelich GmbH
>>> 52425 Juelich
>>> Sitz der Gesellschaft: Juelich
>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>>> Prof. Dr. Sebastian M. Schmidt
>>> ------------------------------------------------------------
>>> ------------------------------------
>>> ------------------------------------------------------------
>>> ------------------------------------
>>>
>>>
>>>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: Jonas Berndt
Time: Wed Aug 02 06:50:37 2017
////////////////////////////////////////////////////////////////////////////////
//
// Point-Stat configuration file.
//
// For additional information, see the MET_BASE/config/README file.
//
////////////////////////////////////////////////////////////////////////////////
//
// Output model name to be written
//
model = "WRF";
////////////////////////////////////////////////////////////////////////////////
//
// Verification grid
//
regrid = {
to_grid = NONE;
method = NEAREST;
width = 1;
vld_thresh = 0.5;
}
////////////////////////////////////////////////////////////////////////////////
cat_thresh = [ NA ];
cnt_thresh = [ NA ];
cnt_logic = UNION;
//wind_thresh = [ >0.0, >=1.0, >=5.0, >=8.0 ];
wind_thresh = [];
wind_logic = UNION;
//
// Forecast and observation fields to be verified
//
fcst = {
message_type = [ "ADPUPA" ];
sid_exc = [];
field = [
// {
// name = "WIND";
// level = "Z10";
// cat_thresh = [>0.0];
// }
{
name = "WIND";
level = "P850-500";
//cat_thresh = [<=273.0];
}
];
}
obs = {
message_type = [ "ADPUPA" ];
sid_exc = [];
field = [
// {
// name = "WIND";
// level = "Z10";
// cat_thresh = [>0.0];
// }
{
name = "WIND";
level = "P850-500";
//cat_thresh = [<=273.0];
}
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Climatology mean data
//
climo_mean = {
file_name = [];
field = [];
regrid = {
method = NEAREST;
width = 1;
vld_thresh = 0.5;
}
time_interp_method = DW_MEAN;
match_day = FALSE;
time_step = 21600;
}
////////////////////////////////////////////////////////////////////////////////
//
// Point observation time window
//
obs_window = {
beg = -3600;
end = 3600;
}
////////////////////////////////////////////////////////////////////////////////
//
// Verification masking regions
//
mask = {
grid = [];
poly = [ "germany.poly" ];
}
////////////////////////////////////////////////////////////////////////////////
//
// Confidence interval settings
//
ci_alpha = [ 0.05 ];
boot = {
interval = PCTILE;
rep_prop = 1.0;
n_rep = 0;
rng = "mt19937";
seed = "";
}
////////////////////////////////////////////////////////////////////////////////
//
// Interpolation methods
//
interp = {
vld_thresh = 1.0;
type = [
{
method = NEAREST;
width = 1;
}
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Statistical output types
//
output_flag = {
fho = NONE;
ctc = BOTH;
cts = BOTH;
mctc = BOTH;
mcts = BOTH;
cnt = BOTH;
sl1l2 = BOTH;
sal1l2 = NONE;
vl1l2 = BOTH;
val1l2 = NONE;
pct = NONE;
pstd = NONE;
pjc = NONE;
prc = NONE;
mpr = BOTH;
}
////////////////////////////////////////////////////////////////////////////////
obs_quality = [ "9" ];
duplicate_flag = NONE;
rank_corr_flag = FALSE;
tmp_dir = "/tmp";
output_prefix = "";
version = "V5.2";
////////////////////////////////////////////////////////////////////////////////
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Wed Aug 16 09:59:07 2017
Jonas,
I apologize for the very late response to your questions! I let this
slip
through the cracks.
(1) I see that you're still getting 0 matched pairs. If there is a
specific forecast file and observation file you'd like to me to test
out,
yes, please do post them either to your FTP site our anonymous one
following these instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
(2) You are correct, the MET tools do not currently consider any
topography
information when interpolating data from model grid points to point
observation locations. It has not yet been included because the
verification algorithms from NOAA/NCEP on which MET was originally
based do
not include them. But this issue has been raised in the past.
I'm looking for a little input here. Do you have any specific
suggestions
for how you'd like to see topography and land/sea mask used when
computing
matched pairs? Should we just allow a configurable elevation
tolerance and
exclude model grid points that aren't "close enough" in elevation to
the
observation? That would be pretty easy to implement. Or should we
still
use the model grid points but apply some correction for the elevation
difference?
What have you guys done in the past?
(3) I don't see anything obvious in your Point-Stat config file that'd
cause 0 matched pairs. One very useful thing is rerunning Point-Stat
at a
higher verbosity level (i.e. -v 4). For each verification task, it'll
print to the screen a list of counts for why observations were
excluded.
That should tell you if there's a mismatch between your model and
point
observations in space, time, message type, or vertical level.
Thanks,
John
On Wed, Aug 2, 2017 at 6:50 AM, Jonas Berndt via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>
> Hello John,
>
> sorry for the late answer on this due to days off. I really
appreciate
> your prompt answers on my questions, it helps our research her very
> much. This time I have even three issues which help on would be
highly
> appreciated.
>
> _1. Concerning: the issue of comparing station pressure to model
data:_
> The problem was indeed in the first place, that pressure was not
defined
> as an observation. I always downloaded the subsets that already
> ran through the PB2NC tool for NCEP assimilation. Now, I run through
> PB2NC as you have told me and this works.
> Nevertheless, I could not find matching pairs of observations and
model
> data for station pressure. I expect the observations of station
pressure
> to be at height Z2.
> I am using the Unified Postprocessor to process WRF data, but even
> though I request SHELTER PRESSURE, it is not included in the GRIB
files.
> Obviously, UPP is not deriving this value. I.e. there is no model
data
> of pressure at height Z2. Only surface pressure is included which
> corresponds to height L1, but this in not the case for observations.
I
> could upload my GRIB and observation file on our ftp if this helps?
>
> 2. _Representativity of surface observations_
> I have a question on representativity of observations. It seems to
me
> that there is no check in the MET tool whether observations and
> gridpoint match certain criteria of geographical equality. Is this
true?
> E.g. I use a 12 km grid and observations and nearest grid point may
be
> off more than 500 meters in height (close to mountains). Or e.g. it
> might be interesting to include solely surface observations with a
> terrain height of e.g. below 150 meters (as it is done in some data
> assimilation schemes for wind). Does MET provide some flags for
checking
> this?
>
> 3. _Upper air observations (ADPUPA)_
> I want to compare upper air observations from radiosondes. MET does
not
> find any pairs. I attached the PointStatConfig file. Do you see
anything
> suspicious? I ensured that ADPUPA observations are in the
observation
> file. I checked this with the plot_point_obs tool. I also set the
> obs_window correct to include such observations.
>
> Thanks a lot John for any kind of help on this,
> Jonas
>
> On 07/07/2017 06:01 PM, John Halley Gotway via RT wrote:
> > Jonas,
> >
> > OK, I'm pretty sure that MET can already do what you'd like it to
do.
> >
> > The GRIB code abbreviation for pressure is PRES and is GRIB code
#1. All
> > you need to do is request "PRES" in the obs_grib_code
configuration entry
> > in the PB2NC tool. That tells PB2NC to write out pressure as an
> > observation type.
> >
> > Next, you need to configure Point-Stat to do verification at the
surface.
> >
> > The handling of "surface" observations is done in a rather
simplistic
> way.
> > It's basically done by the message type. Message types of ADPSFC
and
> > SFCSHP are assumed to be at the surface... or you can specify
ONLYSF to
> > group those two types together.
> >
> > Just configured Point-Stat to verifying pressure against one of
those
> > surface message types.
> >
> > Please let me know how it goes. If you run into issues, I could
work up
> a
> > more detailed example for you to demonstrate it.
> >
> > Thanks,
> > John
> >
> > On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
> >
> >> Hello Jonas,
> >>
> >> I'm out of the office today, but will take a closer look
tomorrow.
> >>
> >> Thanks
> >> John
> >>
> >> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
> >>>
> >>> Hello John,
> >>>
> >>> thanks as always for your comprehensive answer, though I am
sorry if I
> >>> was not clear enough in my question. I want to compare the model
to
> surface
> >>> pressure, not to pressure reduced to mean sea level.
> >>>
> >>> Surface pressure is not treated as an observation (there is not
a
> >>> particluar GIRB code), but still one has pressure measurements
at the
> >>> surface (e.g. from SYNOP stations). Why aren't they treated as
> observations
> >>> to compare to model values? At least this is done in
assimilation
> systems.
> >>> So why is surface pressure not included in the MET tool? Since
surface
> >>> pressure is not a derived value like PRMSL, it should be more
> meaningful
> >>> especially at high elevations where PRMSL approximations show
quite
> some
> >>> errors.
> >>>
> >>> Thanks a lot,
> >>> Jonas
> >>>
> >>>
> >>>
> >>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
> >>>
> >>> Jonas,
> >>>
> >>> I see that you want to verify forecasts of PRMSL against point
> >>> observations. PRMSL is an observation type that can be derived
by the
> >>> PB2NC tool. You just need to request it in the PB2NC config
file.
> >>>
> >>> Take a look at the description of the obs_grib_code entry for
PB2NC on
> >>> page
> >>> 77 of the MET User's Guide:
> >>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
> >>> Users_Guide_v6.0.pdf
> >>>
> >>> Using the sample data that's distributed with the MET tarball, I
did
> the
> >>> following:
> >>>
> >>> (1) Edit the PB2NC Config file used by the MET test scripts:
> >>> cd met-6.0/scripts
> >>> Edit config/PB2NCConfig_G212 by setting:
> >>>
> >>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
> >>>
> >>> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
> >>>
> >>> (2) Rerun the PB2NC test:
> >>>
> >>> rm pb2nc; make pb2nc
> >>> (3) Run the plot_point_obs tool to visualize the PRMSL locations
> (PRMSL is
> >>> GRIB code 2):
> >>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps -gc
2
> >>>
> >>> (4) I converted the resulting PostScript image to PNG and
attached it.
> >>>
> >>> You'll just need to configure PB2NC to dump out PRMSL
observations, and
> >>> then you'll have them available for the verification step done
in
> >>> Point-Stat. Regarding that step, configure Point-Stat to verify
> against
> >>> surface observations (message_type ADPSFC), water surface
observations
> >>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This is
> >>> mentioned on page 110 of the user's guide.
> >>>
> >>> Hope that helps get you going.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------
> >>> ------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------
> >>> Forschungszentrum Juelich GmbH
> >>> 52425 Juelich
> >>> Sitz der Gesellschaft: Juelich
> >>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
> >>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> >>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
> >>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
> >>> Prof. Dr. Sebastian M. Schmidt
> >>> ------------------------------------------------------------
> >>> ------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------
> >>>
> >>>
> >>>
>
>
>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: Jonas Berndt
Time: Sat Aug 19 10:55:02 2017
Hello John,
no worries and as always thanks for your kind reply.
I uploaded the data to your ftp. The folder is /Berndt_data/. For some
reason I could not upload my configure file, this you find again
attached. I followed your advice to increase verbosity to 4. This
output
is also uploaded. It is quite weird, MET finds matching data in the
grid
file, but not in the observation file. But there are ADPUPA
observation
in the file, as I plotted also with /plot_point_obs. /Actually I wrote
my own little evaluation tool and I find the data in the observation
file. So for sure I am doing something wrong in the configure file. I
increased the masking region to the full model grid an the time window
to +/- 3 hours: still no matching pairs. I am looking forward to your
email telling me what stupid mistake I made there...
Concerning the representativeness of observations: I think as long as
your grid shows some topography, you definitely need something
correction and/or a check if the heights match to a certain degree.
But I think this holds only for surface pressure. As mentioned above,
I
wrote a quite simple evaluation tool myself. I benchmarked my results
with the MET tool. Then I did a sensitivity study, here are some
numbers: A given WRF simulation with 4km hor. resolution shows a RMSE
of
13 hPa for surface pressure over the Germany area (here we have a
mixture: almost no topography to quite steep topography).
Then I include an if clause in my evaluation, asking for matching
pairs
within 50 meters in the vertical, and get a RMSE of 3 hPa, excluding
only a few per cent of the data.
I do the same on temperature and winds: the improvement is very small.
This is not very surprising if you think of the vertical profiles.
In the end I would suggest to include a simple tolerance flag, but
leave
it per default to zero. Then one might argue if you want to include
correction terms as it is done e.g. in data assimilation algorithms,
where one typically faces the issue of observations below the model
sigma domain. I know how they do it from literature, but I do not know
on which variables this is actually applied, besides pressure.
Anyways,
surface winds are normally not used for assimilation in areas of
distinct topography, so only temperature and humidity are left. But I
think this might be something which is worth to test.
Thanks a lot, Cheers,
Jonas
On 08/16/2017 05:59 PM, John Halley Gotway via RT wrote:
> Jonas,
>
> I apologize for the very late response to your questions! I let
this slip
> through the cracks.
>
> (1) I see that you're still getting 0 matched pairs. If there is a
> specific forecast file and observation file you'd like to me to test
out,
> yes, please do post them either to your FTP site our anonymous one
> following these instructions:
>
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> (2) You are correct, the MET tools do not currently consider any
topography
> information when interpolating data from model grid points to point
> observation locations. It has not yet been included because the
> verification algorithms from NOAA/NCEP on which MET was originally
based do
> not include them. But this issue has been raised in the past.
>
> I'm looking for a little input here. Do you have any specific
suggestions
> for how you'd like to see topography and land/sea mask used when
computing
> matched pairs? Should we just allow a configurable elevation
tolerance and
> exclude model grid points that aren't "close enough" in elevation to
the
> observation? That would be pretty easy to implement. Or should we
still
> use the model grid points but apply some correction for the
elevation
> difference?
>
> What have you guys done in the past?
>
> (3) I don't see anything obvious in your Point-Stat config file
that'd
> cause 0 matched pairs. One very useful thing is rerunning Point-
Stat at a
> higher verbosity level (i.e. -v 4). For each verification task,
it'll
> print to the screen a list of counts for why observations were
excluded.
> That should tell you if there's a mismatch between your model and
point
> observations in space, time, message type, or vertical level.
>
> Thanks,
> John
>
> On Wed, Aug 2, 2017 at 6:50 AM, Jonas Berndt via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>
>> Hello John,
>>
>> sorry for the late answer on this due to days off. I really
appreciate
>> your prompt answers on my questions, it helps our research her very
>> much. This time I have even three issues which help on would be
highly
>> appreciated.
>>
>> _1. Concerning: the issue of comparing station pressure to model
data:_
>> The problem was indeed in the first place, that pressure was not
defined
>> as an observation. I always downloaded the subsets that already
>> ran through the PB2NC tool for NCEP assimilation. Now, I run
through
>> PB2NC as you have told me and this works.
>> Nevertheless, I could not find matching pairs of observations and
model
>> data for station pressure. I expect the observations of station
pressure
>> to be at height Z2.
>> I am using the Unified Postprocessor to process WRF data, but even
>> though I request SHELTER PRESSURE, it is not included in the GRIB
files.
>> Obviously, UPP is not deriving this value. I.e. there is no model
data
>> of pressure at height Z2. Only surface pressure is included which
>> corresponds to height L1, but this in not the case for
observations. I
>> could upload my GRIB and observation file on our ftp if this helps?
>>
>> 2. _Representativity of surface observations_
>> I have a question on representativity of observations. It seems to
me
>> that there is no check in the MET tool whether observations and
>> gridpoint match certain criteria of geographical equality. Is this
true?
>> E.g. I use a 12 km grid and observations and nearest grid point may
be
>> off more than 500 meters in height (close to mountains). Or e.g. it
>> might be interesting to include solely surface observations with a
>> terrain height of e.g. below 150 meters (as it is done in some data
>> assimilation schemes for wind). Does MET provide some flags for
checking
>> this?
>>
>> 3. _Upper air observations (ADPUPA)_
>> I want to compare upper air observations from radiosondes. MET does
not
>> find any pairs. I attached the PointStatConfig file. Do you see
anything
>> suspicious? I ensured that ADPUPA observations are in the
observation
>> file. I checked this with the plot_point_obs tool. I also set the
>> obs_window correct to include such observations.
>>
>> Thanks a lot John for any kind of help on this,
>> Jonas
>>
>> On 07/07/2017 06:01 PM, John Halley Gotway via RT wrote:
>>> Jonas,
>>>
>>> OK, I'm pretty sure that MET can already do what you'd like it to
do.
>>>
>>> The GRIB code abbreviation for pressure is PRES and is GRIB code
#1. All
>>> you need to do is request "PRES" in the obs_grib_code
configuration entry
>>> in the PB2NC tool. That tells PB2NC to write out pressure as an
>>> observation type.
>>>
>>> Next, you need to configure Point-Stat to do verification at the
surface.
>>>
>>> The handling of "surface" observations is done in a rather
simplistic
>> way.
>>> It's basically done by the message type. Message types of ADPSFC
and
>>> SFCSHP are assumed to be at the surface... or you can specify
ONLYSF to
>>> group those two types together.
>>>
>>> Just configured Point-Stat to verifying pressure against one of
those
>>> surface message types.
>>>
>>> Please let me know how it goes. If you run into issues, I could
work up
>> a
>>> more detailed example for you to demonstrate it.
>>>
>>> Thanks,
>>> John
>>>
>>> On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway
<johnhg at ucar.edu>
>> wrote:
>>>> Hello Jonas,
>>>>
>>>> I'm out of the office today, but will take a closer look
tomorrow.
>>>>
>>>> Thanks
>>>> John
>>>>
>>>> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu>
>>>> wrote:
>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>>>>
>>>>> Hello John,
>>>>>
>>>>> thanks as always for your comprehensive answer, though I am
sorry if I
>>>>> was not clear enough in my question. I want to compare the model
to
>> surface
>>>>> pressure, not to pressure reduced to mean sea level.
>>>>>
>>>>> Surface pressure is not treated as an observation (there is not
a
>>>>> particluar GIRB code), but still one has pressure measurements
at the
>>>>> surface (e.g. from SYNOP stations). Why aren't they treated as
>> observations
>>>>> to compare to model values? At least this is done in
assimilation
>> systems.
>>>>> So why is surface pressure not included in the MET tool? Since
surface
>>>>> pressure is not a derived value like PRMSL, it should be more
>> meaningful
>>>>> especially at high elevations where PRMSL approximations show
quite
>> some
>>>>> errors.
>>>>>
>>>>> Thanks a lot,
>>>>> Jonas
>>>>>
>>>>>
>>>>>
>>>>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
>>>>>
>>>>> Jonas,
>>>>>
>>>>> I see that you want to verify forecasts of PRMSL against point
>>>>> observations. PRMSL is an observation type that can be derived
by the
>>>>> PB2NC tool. You just need to request it in the PB2NC config
file.
>>>>>
>>>>> Take a look at the description of the obs_grib_code entry for
PB2NC on
>>>>> page
>>>>> 77 of the MET User's Guide:
>>>>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
>>>>> Users_Guide_v6.0.pdf
>>>>>
>>>>> Using the sample data that's distributed with the MET tarball, I
did
>> the
>>>>> following:
>>>>>
>>>>> (1) Edit the PB2NC Config file used by the MET test scripts:
>>>>> cd met-6.0/scripts
>>>>> Edit config/PB2NCConfig_G212 by setting:
>>>>>
>>>>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
>>>>>
>>>>> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
>>>>>
>>>>> (2) Rerun the PB2NC test:
>>>>>
>>>>> rm pb2nc; make pb2nc
>>>>> (3) Run the plot_point_obs tool to visualize the PRMSL locations
>> (PRMSL is
>>>>> GRIB code 2):
>>>>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps
-gc 2
>>>>>
>>>>> (4) I converted the resulting PostScript image to PNG and
attached it.
>>>>>
>>>>> You'll just need to configure PB2NC to dump out PRMSL
observations, and
>>>>> then you'll have them available for the verification step done
in
>>>>> Point-Stat. Regarding that step, configure Point-Stat to verify
>> against
>>>>> surface observations (message_type ADPSFC), water surface
observations
>>>>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This is
>>>>> mentioned on page 110 of the user's guide.
>>>>>
>>>>> Hope that helps get you going.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------------------------
>>>>> ------------------------------------------------------------
>>>>> ------------------------------------
>>>>> Forschungszentrum Juelich GmbH
>>>>> 52425 Juelich
>>>>> Sitz der Gesellschaft: Juelich
>>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B
3498
>>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>>>>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
>>>>> Prof. Dr. Sebastian M. Schmidt
>>>>> ------------------------------------------------------------
>>>>> ------------------------------------
>>>>> ------------------------------------------------------------
>>>>> ------------------------------------
>>>>>
>>>>>
>>>>>
>>
>>
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: Jonas Berndt
Time: Sat Aug 19 10:55:02 2017
////////////////////////////////////////////////////////////////////////////////
//
// Point-Stat configuration file.
//
// For additional information, see the MET_BASE/config/README file.
//
////////////////////////////////////////////////////////////////////////////////
//
// Output model name to be written
//
model = "WRF";
////////////////////////////////////////////////////////////////////////////////
//
// Verification grid
//
regrid = {
to_grid = NONE;
method = NEAREST;
width = 1;
vld_thresh = 0.5;
}
////////////////////////////////////////////////////////////////////////////////
cat_thresh = [ NA ];
cnt_thresh = [ NA ];
cnt_logic = UNION;
//wind_thresh = [ >0.0, >=1.0, >=5.0, >=8.0 ];
wind_thresh = [];
wind_logic = UNION;
//
// Forecast and observation fields to be verified
//
fcst = {
message_type = [ "ADPUPA" ];
sid_exc = [];
field = [
// {
// name = "WIND";
// level = "Z10";
// cat_thresh = [>0.0];
// }
{
name = "WIND";
level = "P850-500";
}
];
}
obs = {
message_type = [ "ADPUPA" ];
sid_exc = [];
field = [
// {
// name = "WIND";
// level = "Z10";
// cat_thresh = [>0.0];
// }
{
name = "WIND";
level = "P850-500";
}
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Climatology mean data
//
climo_mean = {
file_name = [];
field = [];
regrid = {
method = NEAREST;
width = 1;
vld_thresh = 0.5;
}
time_interp_method = DW_MEAN;
match_day = FALSE;
time_step = 21600;
}
////////////////////////////////////////////////////////////////////////////////
//
// Point observation time window
//
obs_window = {
beg = -10800;
end = 10800;
}
////////////////////////////////////////////////////////////////////////////////
//
// Verification masking regions
//
mask = {
grid = ["FULL"];
//poly = [ "germany.poly" ];
poly = [];
}
////////////////////////////////////////////////////////////////////////////////
//
// Confidence interval settings
//
ci_alpha = [ 0.05 ];
boot = {
interval = PCTILE;
rep_prop = 1.0;
n_rep = 0;
rng = "mt19937";
seed = "";
}
////////////////////////////////////////////////////////////////////////////////
//
// Interpolation methods
//
interp = {
vld_thresh = 1.0;
type = [
{
method = NEAREST;
width = 1;
}
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Statistical output types
//
output_flag = {
fho = NONE;
ctc = BOTH;
cts = BOTH;
mctc = BOTH;
mcts = BOTH;
cnt = BOTH;
sl1l2 = BOTH;
sal1l2 = NONE;
vl1l2 = BOTH;
val1l2 = NONE;
pct = NONE;
pstd = NONE;
pjc = NONE;
prc = NONE;
mpr = BOTH;
}
////////////////////////////////////////////////////////////////////////////////
obs_quality = [ "9" ];
duplicate_flag = NONE;
rank_corr_flag = FALSE;
tmp_dir = "/tmp";
output_prefix = "";
version = "V5.2";
////////////////////////////////////////////////////////////////////////////////
------------------------------------------------
Subject: evaluation of mean sea level pressure
From: John Halley Gotway
Time: Wed Aug 23 10:13:42 2017
Jonas,
Thanks for sending you sample data files.
Here are the steps I took:
(1) Run point_stat using your data and verbosity level 4. Here's some
info
I see:
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 301035
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: GRIB code = 253015
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 2145
DEBUG 3: Rejected: level mismatch = 14778
DEBUG 3: Rejected: quality marker = 30384
DEBUG 3: Rejected: message type = 713
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
When verifying WIND speed, observations are being excluded 5 reasons,
listed in this order:
- GRIB code... that makes sense, may observations are not WIND speed.
- level mismatch... that makes sense, may wind speed observations
won't be
between 850 and 500 mb.
- quality marker... Hmm, that makes less sense. Are you sure you want
to
exclude based on quality marker?
- message type... that makes sense, not all observations are of type
ADPUPA.
So of those reasons, we should think more about the quality marker.
(2) Look in your config file at the quality marker setting:
obs_quality = [ "9" ];
This says that you *ONLY* want to use observations whose quality
marker has
a value of 9. I'm guessing what you really mean is 9 or less. But
let's
check to see what quality markers are actually present in your data.
(3) Sometimes looking at observations in the NetCDF file is difficult.
We've included in MET a little Rscript to read the NetCDF point
observation
files and write them out in ascii format:
Rscript met-6.0/scripts/Rscripts/pntnc2ascii.R \
prepbufr.gdas.244565.2014080800.nc >
prepbufr.gdas.244565.2014080800.txt
Then I looked for the unique quality marker entries for ADPUPA
observations
of wind speed (i.e. GRIB code 32):
grep "ADPUPA" prepbufr.gdas.244565.2014080800.txt | grep " 32 " |
awk
'{print $10}' | sort -u
2
6
8
9
I updated your Point-Stat config file to read:
obs_quality = [];
When you give it an empty list, it'll use all the quality markers.
And that results in 1170 matched pairs!
I realize that the quality marker setting is confusing. In PB2NC
config
file, the quality marker is listed as a number:
quality_mark_thresh = 9
That means we keep all quality markers 9 or less.
***BUT*** in the Point-Stat config file, the quality marker is listed
as a
string:
obs_quality = [ "9" ];
And Point-Stat does string matching. The reason for this is that
other
observation sources use strings for observation quality info, like
MADIS.
Also the ascii formats read by ascii2nc also read/write strings.
So hopefully that explains the behavior.
Thanks,
John
On Sat, Aug 19, 2017 at 10:55 AM, Jonas Berndt via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>
> Hello John,
>
> no worries and as always thanks for your kind reply.
>
> I uploaded the data to your ftp. The folder is /Berndt_data/. For
some
> reason I could not upload my configure file, this you find again
> attached. I followed your advice to increase verbosity to 4. This
output
> is also uploaded. It is quite weird, MET finds matching data in the
grid
> file, but not in the observation file. But there are ADPUPA
observation
> in the file, as I plotted also with /plot_point_obs. /Actually I
wrote
> my own little evaluation tool and I find the data in the observation
> file. So for sure I am doing something wrong in the configure file.
I
> increased the masking region to the full model grid an the time
window
> to +/- 3 hours: still no matching pairs. I am looking forward to
your
> email telling me what stupid mistake I made there...
>
> Concerning the representativeness of observations: I think as long
as
> your grid shows some topography, you definitely need something
> correction and/or a check if the heights match to a certain degree.
> But I think this holds only for surface pressure. As mentioned
above, I
> wrote a quite simple evaluation tool myself. I benchmarked my
results
> with the MET tool. Then I did a sensitivity study, here are some
> numbers: A given WRF simulation with 4km hor. resolution shows a
RMSE of
> 13 hPa for surface pressure over the Germany area (here we have a
> mixture: almost no topography to quite steep topography).
> Then I include an if clause in my evaluation, asking for matching
pairs
> within 50 meters in the vertical, and get a RMSE of 3 hPa, excluding
> only a few per cent of the data.
> I do the same on temperature and winds: the improvement is very
small.
> This is not very surprising if you think of the vertical profiles.
>
> In the end I would suggest to include a simple tolerance flag, but
leave
> it per default to zero. Then one might argue if you want to include
> correction terms as it is done e.g. in data assimilation algorithms,
> where one typically faces the issue of observations below the model
> sigma domain. I know how they do it from literature, but I do not
know
> on which variables this is actually applied, besides pressure.
Anyways,
> surface winds are normally not used for assimilation in areas of
> distinct topography, so only temperature and humidity are left. But
I
> think this might be something which is worth to test.
>
> Thanks a lot, Cheers,
>
> Jonas
>
>
>
>
> On 08/16/2017 05:59 PM, John Halley Gotway via RT wrote:
> > Jonas,
> >
> > I apologize for the very late response to your questions! I let
this
> slip
> > through the cracks.
> >
> > (1) I see that you're still getting 0 matched pairs. If there is
a
> > specific forecast file and observation file you'd like to me to
test out,
> > yes, please do post them either to your FTP site our anonymous one
> > following these instructions:
> >
> > http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >
> > (2) You are correct, the MET tools do not currently consider any
> topography
> > information when interpolating data from model grid points to
point
> > observation locations. It has not yet been included because the
> > verification algorithms from NOAA/NCEP on which MET was originally
based
> do
> > not include them. But this issue has been raised in the past.
> >
> > I'm looking for a little input here. Do you have any specific
> suggestions
> > for how you'd like to see topography and land/sea mask used when
> computing
> > matched pairs? Should we just allow a configurable elevation
tolerance
> and
> > exclude model grid points that aren't "close enough" in elevation
to the
> > observation? That would be pretty easy to implement. Or should
we still
> > use the model grid points but apply some correction for the
elevation
> > difference?
> >
> > What have you guys done in the past?
> >
> > (3) I don't see anything obvious in your Point-Stat config file
that'd
> > cause 0 matched pairs. One very useful thing is rerunning Point-
Stat at
> a
> > higher verbosity level (i.e. -v 4). For each verification task,
it'll
> > print to the screen a list of counts for why observations were
excluded.
> > That should tell you if there's a mismatch between your model and
point
> > observations in space, time, message type, or vertical level.
> >
> > Thanks,
> > John
> >
> > On Wed, Aug 2, 2017 at 6:50 AM, Jonas Berndt via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
> >>
> >> Hello John,
> >>
> >> sorry for the late answer on this due to days off. I really
appreciate
> >> your prompt answers on my questions, it helps our research her
very
> >> much. This time I have even three issues which help on would be
highly
> >> appreciated.
> >>
> >> _1. Concerning: the issue of comparing station pressure to model
data:_
> >> The problem was indeed in the first place, that pressure was not
defined
> >> as an observation. I always downloaded the subsets that already
> >> ran through the PB2NC tool for NCEP assimilation. Now, I run
through
> >> PB2NC as you have told me and this works.
> >> Nevertheless, I could not find matching pairs of observations and
model
> >> data for station pressure. I expect the observations of station
pressure
> >> to be at height Z2.
> >> I am using the Unified Postprocessor to process WRF data, but
even
> >> though I request SHELTER PRESSURE, it is not included in the GRIB
files.
> >> Obviously, UPP is not deriving this value. I.e. there is no model
data
> >> of pressure at height Z2. Only surface pressure is included which
> >> corresponds to height L1, but this in not the case for
observations. I
> >> could upload my GRIB and observation file on our ftp if this
helps?
> >>
> >> 2. _Representativity of surface observations_
> >> I have a question on representativity of observations. It seems
to me
> >> that there is no check in the MET tool whether observations and
> >> gridpoint match certain criteria of geographical equality. Is
this true?
> >> E.g. I use a 12 km grid and observations and nearest grid point
may be
> >> off more than 500 meters in height (close to mountains). Or e.g.
it
> >> might be interesting to include solely surface observations with
a
> >> terrain height of e.g. below 150 meters (as it is done in some
data
> >> assimilation schemes for wind). Does MET provide some flags for
checking
> >> this?
> >>
> >> 3. _Upper air observations (ADPUPA)_
> >> I want to compare upper air observations from radiosondes. MET
does not
> >> find any pairs. I attached the PointStatConfig file. Do you see
anything
> >> suspicious? I ensured that ADPUPA observations are in the
observation
> >> file. I checked this with the plot_point_obs tool. I also set the
> >> obs_window correct to include such observations.
> >>
> >> Thanks a lot John for any kind of help on this,
> >> Jonas
> >>
> >> On 07/07/2017 06:01 PM, John Halley Gotway via RT wrote:
> >>> Jonas,
> >>>
> >>> OK, I'm pretty sure that MET can already do what you'd like it
to do.
> >>>
> >>> The GRIB code abbreviation for pressure is PRES and is GRIB code
#1.
> All
> >>> you need to do is request "PRES" in the obs_grib_code
configuration
> entry
> >>> in the PB2NC tool. That tells PB2NC to write out pressure as an
> >>> observation type.
> >>>
> >>> Next, you need to configure Point-Stat to do verification at the
> surface.
> >>>
> >>> The handling of "surface" observations is done in a rather
simplistic
> >> way.
> >>> It's basically done by the message type. Message types of
ADPSFC and
> >>> SFCSHP are assumed to be at the surface... or you can specify
ONLYSF to
> >>> group those two types together.
> >>>
> >>> Just configured Point-Stat to verifying pressure against one of
those
> >>> surface message types.
> >>>
> >>> Please let me know how it goes. If you run into issues, I could
work
> up
> >> a
> >>> more detailed example for you to demonstrate it.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>> On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway
<johnhg at ucar.edu>
> >> wrote:
> >>>> Hello Jonas,
> >>>>
> >>>> I'm out of the office today, but will take a closer look
tomorrow.
> >>>>
> >>>> Thanks
> >>>> John
> >>>>
> >>>> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu
> >
> >>>> wrote:
> >>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014
>
> >>>>>
> >>>>> Hello John,
> >>>>>
> >>>>> thanks as always for your comprehensive answer, though I am
sorry if
> I
> >>>>> was not clear enough in my question. I want to compare the
model to
> >> surface
> >>>>> pressure, not to pressure reduced to mean sea level.
> >>>>>
> >>>>> Surface pressure is not treated as an observation (there is
not a
> >>>>> particluar GIRB code), but still one has pressure measurements
at the
> >>>>> surface (e.g. from SYNOP stations). Why aren't they treated as
> >> observations
> >>>>> to compare to model values? At least this is done in
assimilation
> >> systems.
> >>>>> So why is surface pressure not included in the MET tool? Since
> surface
> >>>>> pressure is not a derived value like PRMSL, it should be more
> >> meaningful
> >>>>> especially at high elevations where PRMSL approximations show
quite
> >> some
> >>>>> errors.
> >>>>>
> >>>>> Thanks a lot,
> >>>>> Jonas
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
> >>>>>
> >>>>> Jonas,
> >>>>>
> >>>>> I see that you want to verify forecasts of PRMSL against point
> >>>>> observations. PRMSL is an observation type that can be
derived by
> the
> >>>>> PB2NC tool. You just need to request it in the PB2NC config
file.
> >>>>>
> >>>>> Take a look at the description of the obs_grib_code entry for
PB2NC
> on
> >>>>> page
> >>>>> 77 of the MET User's Guide:
> >>>>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
> >>>>> Users_Guide_v6.0.pdf
> >>>>>
> >>>>> Using the sample data that's distributed with the MET tarball,
I did
> >> the
> >>>>> following:
> >>>>>
> >>>>> (1) Edit the PB2NC Config file used by the MET test scripts:
> >>>>> cd met-6.0/scripts
> >>>>> Edit config/PB2NCConfig_G212 by setting:
> >>>>>
> >>>>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
> >>>>>
> >>>>> "DPT", "WIND", "RH", "MIXR", "PRMSL" ];
> >>>>>
> >>>>> (2) Rerun the PB2NC test:
> >>>>>
> >>>>> rm pb2nc; make pb2nc
> >>>>> (3) Run the plot_point_obs tool to visualize the PRMSL
locations
> >> (PRMSL is
> >>>>> GRIB code 2):
> >>>>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps
-gc 2
> >>>>>
> >>>>> (4) I converted the resulting PostScript image to PNG and
attached
> it.
> >>>>>
> >>>>> You'll just need to configure PB2NC to dump out PRMSL
observations,
> and
> >>>>> then you'll have them available for the verification step done
in
> >>>>> Point-Stat. Regarding that step, configure Point-Stat to
verify
> >> against
> >>>>> surface observations (message_type ADPSFC), water surface
> observations
> >>>>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This
> is
> >>>>> mentioned on page 110 of the user's guide.
> >>>>>
> >>>>> Hope that helps get you going.
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> >>>>> ------------------------------------
> >>>>> ------------------------------------------------------------
> >>>>> ------------------------------------
> >>>>> Forschungszentrum Juelich GmbH
> >>>>> 52425 Juelich
> >>>>> Sitz der Gesellschaft: Juelich
> >>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR
B 3498
> >>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen
Huthmacher
> >>>>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
> >>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
> >>>>> Prof. Dr. Sebastian M. Schmidt
> >>>>> ------------------------------------------------------------
> >>>>> ------------------------------------
> >>>>> ------------------------------------------------------------
> >>>>> ------------------------------------
> >>>>>
> >>>>>
> >>>>>
> >>
> >>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #81014] evaluation of mean sea level pressure
From: Jonas Berndt
Time: Sun Aug 27 03:40:47 2017
John,
thank you very much for your work and time you put into this.
Indeed, the quality marker is a bit confusing. As you guessed
correctly:
I kept this definition in mind from the PB2NC and transferred this to
Point-Stat.
Now it works just fine.
Best regards,
Jonas
On 08/23/2017 06:13 PM, John Halley Gotway via RT wrote:
> Jonas,
>
> Thanks for sending you sample data files.
>
> Here are the steps I took:
>
> (1) Run point_stat using your data and verbosity level 4. Here's
some info
> I see:
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 301035
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: GRIB code = 253015
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 2145
> DEBUG 3: Rejected: level mismatch = 14778
> DEBUG 3: Rejected: quality marker = 30384
> DEBUG 3: Rejected: message type = 713
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
>
> When verifying WIND speed, observations are being excluded 5
reasons,
> listed in this order:
> - GRIB code... that makes sense, may observations are not WIND
speed.
> - level mismatch... that makes sense, may wind speed observations
won't be
> between 850 and 500 mb.
> - quality marker... Hmm, that makes less sense. Are you sure you
want to
> exclude based on quality marker?
> - message type... that makes sense, not all observations are of type
ADPUPA.
>
> So of those reasons, we should think more about the quality marker.
>
> (2) Look in your config file at the quality marker setting:
> obs_quality = [ "9" ];
>
> This says that you *ONLY* want to use observations whose quality
marker has
> a value of 9. I'm guessing what you really mean is 9 or less. But
let's
> check to see what quality markers are actually present in your data.
>
> (3) Sometimes looking at observations in the NetCDF file is
difficult.
> We've included in MET a little Rscript to read the NetCDF point
observation
> files and write them out in ascii format:
>
> Rscript met-6.0/scripts/Rscripts/pntnc2ascii.R \
> prepbufr.gdas.244565.2014080800.nc >
prepbufr.gdas.244565.2014080800.txt
>
> Then I looked for the unique quality marker entries for ADPUPA
observations
> of wind speed (i.e. GRIB code 32):
> grep "ADPUPA" prepbufr.gdas.244565.2014080800.txt | grep " 32 "
| awk
> '{print $10}' | sort -u
> 2
> 6
> 8
> 9
>
> I updated your Point-Stat config file to read:
> obs_quality = [];
>
> When you give it an empty list, it'll use all the quality markers.
>
> And that results in 1170 matched pairs!
>
> I realize that the quality marker setting is confusing. In PB2NC
config
> file, the quality marker is listed as a number:
> quality_mark_thresh = 9
>
> That means we keep all quality markers 9 or less.
>
> ***BUT*** in the Point-Stat config file, the quality marker is
listed as a
> string:
> obs_quality = [ "9" ];
>
> And Point-Stat does string matching. The reason for this is that
other
> observation sources use strings for observation quality info, like
MADIS.
> Also the ascii formats read by ascii2nc also read/write strings.
>
> So hopefully that explains the behavior.
>
> Thanks,
> John
>
>
>
>
>
>
>
> On Sat, Aug 19, 2017 at 10:55 AM, Jonas Berndt via RT
<met_help at ucar.edu>
> wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>
>> Hello John,
>>
>> no worries and as always thanks for your kind reply.
>>
>> I uploaded the data to your ftp. The folder is /Berndt_data/. For
some
>> reason I could not upload my configure file, this you find again
>> attached. I followed your advice to increase verbosity to 4. This
output
>> is also uploaded. It is quite weird, MET finds matching data in the
grid
>> file, but not in the observation file. But there are ADPUPA
observation
>> in the file, as I plotted also with /plot_point_obs. /Actually I
wrote
>> my own little evaluation tool and I find the data in the
observation
>> file. So for sure I am doing something wrong in the configure file.
I
>> increased the masking region to the full model grid an the time
window
>> to +/- 3 hours: still no matching pairs. I am looking forward to
your
>> email telling me what stupid mistake I made there...
>>
>> Concerning the representativeness of observations: I think as long
as
>> your grid shows some topography, you definitely need something
>> correction and/or a check if the heights match to a certain degree.
>> But I think this holds only for surface pressure. As mentioned
above, I
>> wrote a quite simple evaluation tool myself. I benchmarked my
results
>> with the MET tool. Then I did a sensitivity study, here are some
>> numbers: A given WRF simulation with 4km hor. resolution shows a
RMSE of
>> 13 hPa for surface pressure over the Germany area (here we have a
>> mixture: almost no topography to quite steep topography).
>> Then I include an if clause in my evaluation, asking for matching
pairs
>> within 50 meters in the vertical, and get a RMSE of 3 hPa,
excluding
>> only a few per cent of the data.
>> I do the same on temperature and winds: the improvement is very
small.
>> This is not very surprising if you think of the vertical profiles.
>>
>> In the end I would suggest to include a simple tolerance flag, but
leave
>> it per default to zero. Then one might argue if you want to include
>> correction terms as it is done e.g. in data assimilation
algorithms,
>> where one typically faces the issue of observations below the model
>> sigma domain. I know how they do it from literature, but I do not
know
>> on which variables this is actually applied, besides pressure.
Anyways,
>> surface winds are normally not used for assimilation in areas of
>> distinct topography, so only temperature and humidity are left. But
I
>> think this might be something which is worth to test.
>>
>> Thanks a lot, Cheers,
>>
>> Jonas
>>
>>
>>
>>
>> On 08/16/2017 05:59 PM, John Halley Gotway via RT wrote:
>>> Jonas,
>>>
>>> I apologize for the very late response to your questions! I let
this
>> slip
>>> through the cracks.
>>>
>>> (1) I see that you're still getting 0 matched pairs. If there is
a
>>> specific forecast file and observation file you'd like to me to
test out,
>>> yes, please do post them either to your FTP site our anonymous one
>>> following these instructions:
>>>
>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>
>>> (2) You are correct, the MET tools do not currently consider any
>> topography
>>> information when interpolating data from model grid points to
point
>>> observation locations. It has not yet been included because the
>>> verification algorithms from NOAA/NCEP on which MET was originally
based
>> do
>>> not include them. But this issue has been raised in the past.
>>>
>>> I'm looking for a little input here. Do you have any specific
>> suggestions
>>> for how you'd like to see topography and land/sea mask used when
>> computing
>>> matched pairs? Should we just allow a configurable elevation
tolerance
>> and
>>> exclude model grid points that aren't "close enough" in elevation
to the
>>> observation? That would be pretty easy to implement. Or should
we still
>>> use the model grid points but apply some correction for the
elevation
>>> difference?
>>>
>>> What have you guys done in the past?
>>>
>>> (3) I don't see anything obvious in your Point-Stat config file
that'd
>>> cause 0 matched pairs. One very useful thing is rerunning Point-
Stat at
>> a
>>> higher verbosity level (i.e. -v 4). For each verification task,
it'll
>>> print to the screen a list of counts for why observations were
excluded.
>>> That should tell you if there's a mismatch between your model and
point
>>> observations in space, time, message type, or vertical level.
>>>
>>> Thanks,
>>> John
>>>
>>> On Wed, Aug 2, 2017 at 6:50 AM, Jonas Berndt via RT
<met_help at ucar.edu>
>>> wrote:
>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014 >
>>>>
>>>> Hello John,
>>>>
>>>> sorry for the late answer on this due to days off. I really
appreciate
>>>> your prompt answers on my questions, it helps our research her
very
>>>> much. This time I have even three issues which help on would be
highly
>>>> appreciated.
>>>>
>>>> _1. Concerning: the issue of comparing station pressure to model
data:_
>>>> The problem was indeed in the first place, that pressure was not
defined
>>>> as an observation. I always downloaded the subsets that already
>>>> ran through the PB2NC tool for NCEP assimilation. Now, I run
through
>>>> PB2NC as you have told me and this works.
>>>> Nevertheless, I could not find matching pairs of observations and
model
>>>> data for station pressure. I expect the observations of station
pressure
>>>> to be at height Z2.
>>>> I am using the Unified Postprocessor to process WRF data, but
even
>>>> though I request SHELTER PRESSURE, it is not included in the GRIB
files.
>>>> Obviously, UPP is not deriving this value. I.e. there is no model
data
>>>> of pressure at height Z2. Only surface pressure is included which
>>>> corresponds to height L1, but this in not the case for
observations. I
>>>> could upload my GRIB and observation file on our ftp if this
helps?
>>>>
>>>> 2. _Representativity of surface observations_
>>>> I have a question on representativity of observations. It seems
to me
>>>> that there is no check in the MET tool whether observations and
>>>> gridpoint match certain criteria of geographical equality. Is
this true?
>>>> E.g. I use a 12 km grid and observations and nearest grid point
may be
>>>> off more than 500 meters in height (close to mountains). Or e.g.
it
>>>> might be interesting to include solely surface observations with
a
>>>> terrain height of e.g. below 150 meters (as it is done in some
data
>>>> assimilation schemes for wind). Does MET provide some flags for
checking
>>>> this?
>>>>
>>>> 3. _Upper air observations (ADPUPA)_
>>>> I want to compare upper air observations from radiosondes. MET
does not
>>>> find any pairs. I attached the PointStatConfig file. Do you see
anything
>>>> suspicious? I ensured that ADPUPA observations are in the
observation
>>>> file. I checked this with the plot_point_obs tool. I also set the
>>>> obs_window correct to include such observations.
>>>>
>>>> Thanks a lot John for any kind of help on this,
>>>> Jonas
>>>>
>>>> On 07/07/2017 06:01 PM, John Halley Gotway via RT wrote:
>>>>> Jonas,
>>>>>
>>>>> OK, I'm pretty sure that MET can already do what you'd like it
to do.
>>>>>
>>>>> The GRIB code abbreviation for pressure is PRES and is GRIB code
#1.
>> All
>>>>> you need to do is request "PRES" in the obs_grib_code
configuration
>> entry
>>>>> in the PB2NC tool. That tells PB2NC to write out pressure as an
>>>>> observation type.
>>>>>
>>>>> Next, you need to configure Point-Stat to do verification at the
>> surface.
>>>>> The handling of "surface" observations is done in a rather
simplistic
>>>> way.
>>>>> It's basically done by the message type. Message types of
ADPSFC and
>>>>> SFCSHP are assumed to be at the surface... or you can specify
ONLYSF to
>>>>> group those two types together.
>>>>>
>>>>> Just configured Point-Stat to verifying pressure against one of
those
>>>>> surface message types.
>>>>>
>>>>> Please let me know how it goes. If you run into issues, I could
work
>> up
>>>> a
>>>>> more detailed example for you to demonstrate it.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On Thu, Jul 6, 2017 at 8:39 AM, John Halley Gotway
<johnhg at ucar.edu>
>>>> wrote:
>>>>>> Hello Jonas,
>>>>>>
>>>>>> I'm out of the office today, but will take a closer look
tomorrow.
>>>>>>
>>>>>> Thanks
>>>>>> John
>>>>>>
>>>>>> On Thu, Jul 6, 2017 at 8:55 AM Jonas Berndt via RT
<met_help at ucar.edu
>>>>>> wrote:
>>>>>>
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81014
>
>>>>>>>
>>>>>>> Hello John,
>>>>>>>
>>>>>>> thanks as always for your comprehensive answer, though I am
sorry if
>> I
>>>>>>> was not clear enough in my question. I want to compare the
model to
>>>> surface
>>>>>>> pressure, not to pressure reduced to mean sea level.
>>>>>>>
>>>>>>> Surface pressure is not treated as an observation (there is
not a
>>>>>>> particluar GIRB code), but still one has pressure measurements
at the
>>>>>>> surface (e.g. from SYNOP stations). Why aren't they treated as
>>>> observations
>>>>>>> to compare to model values? At least this is done in
assimilation
>>>> systems.
>>>>>>> So why is surface pressure not included in the MET tool? Since
>> surface
>>>>>>> pressure is not a derived value like PRMSL, it should be more
>>>> meaningful
>>>>>>> especially at high elevations where PRMSL approximations show
quite
>>>> some
>>>>>>> errors.
>>>>>>>
>>>>>>> Thanks a lot,
>>>>>>> Jonas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 07/03/2017 06:14 PM, John Halley Gotway via RT wrote:
>>>>>>>
>>>>>>> Jonas,
>>>>>>>
>>>>>>> I see that you want to verify forecasts of PRMSL against point
>>>>>>> observations. PRMSL is an observation type that can be
derived by
>> the
>>>>>>> PB2NC tool. You just need to request it in the PB2NC config
file.
>>>>>>>
>>>>>>> Take a look at the description of the obs_grib_code entry for
PB2NC
>> on
>>>>>>> page
>>>>>>> 77 of the MET User's Guide:
>>>>>>> http://www.dtcenter.org/met/users/docs/users_guide/MET_
>>>>>>> Users_Guide_v6.0.pdf
>>>>>>>
>>>>>>> Using the sample data that's distributed with the MET tarball,
I did
>>>> the
>>>>>>> following:
>>>>>>>
>>>>>>> (1) Edit the PB2NC Config file used by the MET test scripts:
>>>>>>> cd met-6.0/scripts
>>>>>>> Edit config/PB2NCConfig_G212 by setting:
>>>>>>>
>>>>>>> obs_grib_code = [ "SPFH", "TMP", "HGT", "UGRD", "VGRD",
>>>>>>>
>>>>>>> "DPT", "WIND", "RH", "MIXR", "PRMSL"
];
>>>>>>>
>>>>>>> (2) Rerun the PB2NC test:
>>>>>>>
>>>>>>> rm pb2nc; make pb2nc
>>>>>>> (3) Run the plot_point_obs tool to visualize the PRMSL
locations
>>>> (PRMSL is
>>>>>>> GRIB code 2):
>>>>>>> ../bin/plot_point_obs ../out/pb2nc/sample_pb.nc prmsl.ps
-gc 2
>>>>>>>
>>>>>>> (4) I converted the resulting PostScript image to PNG and
attached
>> it.
>>>>>>> You'll just need to configure PB2NC to dump out PRMSL
observations,
>> and
>>>>>>> then you'll have them available for the verification step done
in
>>>>>>> Point-Stat. Regarding that step, configure Point-Stat to
verify
>>>> against
>>>>>>> surface observations (message_type ADPSFC), water surface
>> observations
>>>>>>> (message_type SFCSHP), or both combined (message_type ONLYSF).
This
>> is
>>>>>>> mentioned on page 110 of the user's guide.
>>>>>>>
>>>>>>> Hope that helps get you going.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------
>>>>>>> Forschungszentrum Juelich GmbH
>>>>>>> 52425 Juelich
>>>>>>> Sitz der Gesellschaft: Juelich
>>>>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR
B 3498
>>>>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen
Huthmacher
>>>>>>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
(Vorsitzender),
>>>>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald
Bolt,
>>>>>>> Prof. Dr. Sebastian M. Schmidt
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>>
------------------------------------------------
More information about the Met_help
mailing list