[Met_help] [rt.rap.ucar.edu #90808] History for 0-pair match issue in ensemble_stat
John Halley Gotway via RT
met_help at ucar.edu
Tue Jul 2 12:23:45 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I tested following your suggests. It works! Only issue is for PRMSL (Mean Sea Level Pressure).
I looked at PRMSL in prepbufr files and found it has no quality marker (symboled as * ).
In NC file after pb2nc, PRMSL has marker with symbal "NA". If set obs_quality = [ "1", "2", "9" ];
all other fields have no problem except that PRMSL has 0-pair match. I tested the setting
obs_quality = [ "1", "2", "9", "NA" ]; This setting works well for all fields including PRMSL.
Pretty interesting. I am not for sure if there are any other fields with quality marker "NA".
I have asked our prepbufr team about how come the quality markers were changed to 9 for T2m and
"NA" for PRMSL. Since "9" means questioned data in prepbufr They will investigate this issue.
For us, we just make our verification work.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: John Halley Gotway
Time: Wed Jun 26 09:48:54 2019
Binbin,
I turned your email into a met-help question in case others on our
team are able to help.
Glad you've been able to make progress. But I don't understand what's
going on with PRMSL. That observation does not actually exist in the
input PREPBUFR file. Instead, it's derived from other observations...
just like DPT, WDIR, WIND, RH, and MIXR are also derived from other
obs.
I reran PB2NC on a sample GDAS file from 20190612
(gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior you
describe. I configured PB2NC to request all the native and derived
variable types:
obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_DPT",
"D_WDIR", "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
Of the 36,913 PRMSL observations:
- 35,359 have QM = 9
- 205 have QM = 8
- 6 have QM = 6
- 323 have QM = 14
- 1020 have QM = 15
But there are no observations with an NA quality marker. Do you
happen to have the PREPBUFR file and PB2NC config file which produced
the NA quality marker?
One more detail. You do have the option of configuring which quality
markers are used for each variable in the Point-Stat config file. You
just define the obs_quality entry separately for each variable. For
example, use 1, 2, and 9 for 2-m temperature and only 1 and 2 for
500mb temperature:
obs = {
field = [
{ name = "TMP"; level = "Z2"; obs_quality = [ "1", "2", "9" ];
},
{ name = "TMP"; level = "P500"; obs_quality = [ "1", "2" ]; }
];
}
Thanks,
John
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: Binbin.Zhou at noaa.gov
Time: Wed Jun 26 13:15:35 2019
John,
Thanks for further guideline for using obs_quality. It seems
prepbufr
has no problem.
This issue only appears after 20190612. I have copied 20190623 12Z
prepbufr
file to
theia in
directory /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
The file name is gfs.t12z.prepbufr
I used PB2NCConfig_gens.P(in the same directory) to test. In this
config
file only PRMSL is specified.
The resultant file is gfs.t12z.prebufr.f00.P.nc. From this file you
can see
the QM marker is "NA".
Binbin
On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Binbin,
>
> I turned your email into a met-help question in case others on our
team
> are able to help.
>
> Glad you've been able to make progress. But I don't understand
what's
> going on with PRMSL. That observation does not actually exist in
the input
> PREPBUFR file. Instead, it's derived from other observations...
just like
> DPT, WDIR, WIND, RH, and MIXR are also derived from other obs.
>
> I reran PB2NC on a sample GDAS file from 20190612 (
> gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior you
> describe. I configured PB2NC to request all the native and derived
> variable types:
>
> obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_DPT",
"D_WDIR",
> "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
>
> Of the 36,913 PRMSL observations:
> - 35,359 have QM = 9
> - 205 have QM = 8
> - 6 have QM = 6
> - 323 have QM = 14
> - 1020 have QM = 15
>
> But there are no observations with an NA quality marker. Do you
happen to
> have the PREPBUFR file and PB2NC config file which produced the NA
quality
> marker?
>
> One more detail. You do have the option of configuring which
quality
> markers are used for each variable in the Point-Stat config file.
You just
> define the obs_quality entry separately for each variable. For
example,
> use 1, 2, and 9 for 2-m temperature and only 1 and 2 for 500mb
temperature:
>
> obs = {
> field = [
> { name = "TMP"; level = "Z2"; obs_quality = [ "1", "2", "9"
]; },
> { name = "TMP"; level = "P500"; obs_quality = [ "1", "2" ]; }
> ];
> }
>
>
> Thanks,
> John
>
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: John Halley Gotway
Time: Mon Jul 01 15:08:40 2019
Binbin,
I went looking on theia this afternoon and found that the permissions
on
that prepbufr file are locked down:
[John.H.Gotway at tfe02 g2o_ensemble_ADPSFC]$ ls -la
/scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
-rw-r----- 1 Binbin.Zhou fv3-cam 78761312 Jun 26 18:54
/scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
I'm not in the fv3-cam group, so I'm not able to read it.
John
On Wed, Jun 26, 2019 at 1:15 PM Binbin.Zhou at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
>
> John,
>
> Thanks for further guideline for using obs_quality. It seems
prepbufr
> has no problem.
> This issue only appears after 20190612. I have copied 20190623 12Z
prepbufr
> file to
> theia in
> directory
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
> The file name is gfs.t12z.prepbufr
>
> I used PB2NCConfig_gens.P(in the same directory) to test. In this
config
> file only PRMSL is specified.
> The resultant file is gfs.t12z.prebufr.f00.P.nc. From this file you
can
> see
> the QM marker is "NA".
>
> Binbin
>
> On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Binbin,
> >
> > I turned your email into a met-help question in case others on our
team
> > are able to help.
> >
> > Glad you've been able to make progress. But I don't understand
what's
> > going on with PRMSL. That observation does not actually exist in
the
> input
> > PREPBUFR file. Instead, it's derived from other observations...
just
> like
> > DPT, WDIR, WIND, RH, and MIXR are also derived from other obs.
> >
> > I reran PB2NC on a sample GDAS file from 20190612 (
> > gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior you
> > describe. I configured PB2NC to request all the native and
derived
> > variable types:
> >
> > obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_DPT",
"D_WDIR",
> > "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
> >
> > Of the 36,913 PRMSL observations:
> > - 35,359 have QM = 9
> > - 205 have QM = 8
> > - 6 have QM = 6
> > - 323 have QM = 14
> > - 1020 have QM = 15
> >
> > But there are no observations with an NA quality marker. Do you
happen
> to
> > have the PREPBUFR file and PB2NC config file which produced the NA
> quality
> > marker?
> >
> > One more detail. You do have the option of configuring which
quality
> > markers are used for each variable in the Point-Stat config file.
You
> just
> > define the obs_quality entry separately for each variable. For
example,
> > use 1, 2, and 9 for 2-m temperature and only 1 and 2 for 500mb
> temperature:
> >
> > obs = {
> > field = [
> > { name = "TMP"; level = "Z2"; obs_quality = [ "1", "2",
"9" ]; },
> > { name = "TMP"; level = "P500"; obs_quality = [ "1", "2" ];
}
> > ];
> > }
> >
> >
> > Thanks,
> > John
> >
>
>
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: John Halley Gotway
Time: Mon Jul 01 15:26:55 2019
Binbin,
I was able to locate some prepbufr files for testing on an ftp site.
I
pulled a GFS and GDAS prepbufr file for the same time:
*wget
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20190628/12/gfs.t12z.prepbufr.nr
<https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gfs.20190628/12/gfs.t12z.prepbufr.nr>wget
https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gdas.20190628/12/gdas.t12z.prepbufr.nr
<https://nomads.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gdas.20190628/12/gdas.t12z.prepbufr.nr>*
Indeed the PRMSL observations in the output of PB2NC have a quality
marker
of "NA" for both.
But I do see the source of the confusion! In your config file, you're
reading the "PMO" observation type and then naming it "PRMSL" in the
output:
*obs_bufr_var = [ "PMO" ];obs_bufr_map = [ { key = "PMO" ; val =
"PRMSL";
};];*
So it's the *PMO* observation that has a quality marker of NA. I had
been
using the following settings in my PB2NC config file for testing:
*obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_PRMSL"
];obs_prefbufr_map = [ { key = "POB"; val = "PRES"; }, { key
=
"QOB"; val = "SPFH"; }, { key = "TOB"; val = "TMP"; },
{ key
= "ZOB"; val = "HGT"; }, { key = "UOB"; val = "UGRD"; },
{
key = "VOB"; val = "VGRD"; }, { key = "D_DPT"; val = "DPT";
},
{ key = "D_WDIR"; val = "WDIR"; }, { key = "D_WIND"; val =
"WIND";
}, { key = "D_RH"; val = "RH"; }, { key = "D_MIXR"; val =
"MIXR"; }, { key = "D_PRMSL"; val = "PRMSL"; }];*
By requesting "D_PRMSL" were ask PB2NC to derive PRMSL on the fly from
the
other obs variables. And doing it this way results in PRMSL
observations
with quality marker values of 2, 8, or 9... which are the quality
flags for
the component obs that go into the computation.
So the question really is... should you use "POM" observations
directly or
should you derived "PRMSL" from the other observations (p, q, t, z, u,
v)?
And I really don't have a good answer for you. In fact, this is the
first
I've ever heard of the POM observation variable. It would be pretty
interesting to do a scatter plot of POM vs D_PRMSL to see how close
they
are.
But at least we can explain the source of the difference!
Hope that helps.
Thanks,
John
On Mon, Jul 1, 2019 at 3:08 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Binbin,
>
> I went looking on theia this afternoon and found that the
permissions on
> that prepbufr file are locked down:
>
> [John.H.Gotway at tfe02 g2o_ensemble_ADPSFC]$ ls -la
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> -rw-r----- 1 Binbin.Zhou fv3-cam 78761312 Jun 26 18:54
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
>
> I'm not in the fv3-cam group, so I'm not able to read it.
>
> John
>
> On Wed, Jun 26, 2019 at 1:15 PM Binbin.Zhou at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
>>
>> John,
>>
>> Thanks for further guideline for using obs_quality. It seems
prepbufr
>> has no problem.
>> This issue only appears after 20190612. I have copied 20190623 12Z
>> prepbufr
>> file to
>> theia in
>> directory
>> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
>> The file name is gfs.t12z.prepbufr
>>
>> I used PB2NCConfig_gens.P(in the same directory) to test. In this
config
>> file only PRMSL is specified.
>> The resultant file is gfs.t12z.prebufr.f00.P.nc. From this file you
can
>> see
>> the QM marker is "NA".
>>
>> Binbin
>>
>> On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>
>> > Binbin,
>> >
>> > I turned your email into a met-help question in case others on
our team
>> > are able to help.
>> >
>> > Glad you've been able to make progress. But I don't understand
what's
>> > going on with PRMSL. That observation does not actually exist in
the
>> input
>> > PREPBUFR file. Instead, it's derived from other observations...
just
>> like
>> > DPT, WDIR, WIND, RH, and MIXR are also derived from other obs.
>> >
>> > I reran PB2NC on a sample GDAS file from 20190612 (
>> > gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior you
>> > describe. I configured PB2NC to request all the native and
derived
>> > variable types:
>> >
>> > obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_DPT",
>> "D_WDIR",
>> > "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
>> >
>> > Of the 36,913 PRMSL observations:
>> > - 35,359 have QM = 9
>> > - 205 have QM = 8
>> > - 6 have QM = 6
>> > - 323 have QM = 14
>> > - 1020 have QM = 15
>> >
>> > But there are no observations with an NA quality marker. Do you
happen
>> to
>> > have the PREPBUFR file and PB2NC config file which produced the
NA
>> quality
>> > marker?
>> >
>> > One more detail. You do have the option of configuring which
quality
>> > markers are used for each variable in the Point-Stat config file.
You
>> just
>> > define the obs_quality entry separately for each variable. For
example,
>> > use 1, 2, and 9 for 2-m temperature and only 1 and 2 for 500mb
>> temperature:
>> >
>> > obs = {
>> > field = [
>> > { name = "TMP"; level = "Z2"; obs_quality = [ "1", "2",
"9" ];
>> },
>> > { name = "TMP"; level = "P500"; obs_quality = [ "1", "2" ];
}
>> > ];
>> > }
>> >
>> >
>> > Thanks,
>> > John
>> >
>>
>>
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: Binbin.Zhou at noaa.gov
Time: Tue Jul 02 06:39:01 2019
John,
Now you can read and copy, sorry about that.
Binbin
On Mon, Jul 1, 2019 at 5:08 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> I went looking on theia this afternoon and found that the
permissions on
> that prepbufr file are locked down:
>
> [John.H.Gotway at tfe02 g2o_ensemble_ADPSFC]$ ls -la
>
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> -rw-r----- 1 Binbin.Zhou fv3-cam 78761312 Jun 26 18:54
>
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
>
> I'm not in the fv3-cam group, so I'm not able to read it.
>
> John
>
> On Wed, Jun 26, 2019 at 1:15 PM Binbin.Zhou at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
> >
> > John,
> >
> > Thanks for further guideline for using obs_quality. It seems
prepbufr
> > has no problem.
> > This issue only appears after 20190612. I have copied 20190623 12Z
> prepbufr
> > file to
> > theia in
> > directory
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
> > The file name is gfs.t12z.prepbufr
> >
> > I used PB2NCConfig_gens.P(in the same directory) to test. In this
config
> > file only PRMSL is specified.
> > The resultant file is gfs.t12z.prebufr.f00.P.nc. From this file
you can
> > see
> > the QM marker is "NA".
> >
> > Binbin
> >
> > On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Binbin,
> > >
> > > I turned your email into a met-help question in case others on
our team
> > > are able to help.
> > >
> > > Glad you've been able to make progress. But I don't understand
what's
> > > going on with PRMSL. That observation does not actually exist
in the
> > input
> > > PREPBUFR file. Instead, it's derived from other observations...
just
> > like
> > > DPT, WDIR, WIND, RH, and MIXR are also derived from other obs.
> > >
> > > I reran PB2NC on a sample GDAS file from 20190612 (
> > > gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior
you
> > > describe. I configured PB2NC to request all the native and
derived
> > > variable types:
> > >
> > > obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB", "D_DPT",
> "D_WDIR",
> > > "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
> > >
> > > Of the 36,913 PRMSL observations:
> > > - 35,359 have QM = 9
> > > - 205 have QM = 8
> > > - 6 have QM = 6
> > > - 323 have QM = 14
> > > - 1020 have QM = 15
> > >
> > > But there are no observations with an NA quality marker. Do you
happen
> > to
> > > have the PREPBUFR file and PB2NC config file which produced the
NA
> > quality
> > > marker?
> > >
> > > One more detail. You do have the option of configuring which
quality
> > > markers are used for each variable in the Point-Stat config
file. You
> > just
> > > define the obs_quality entry separately for each variable. For
> example,
> > > use 1, 2, and 9 for 2-m temperature and only 1 and 2 for 500mb
> > temperature:
> > >
> > > obs = {
> > > field = [
> > > { name = "TMP"; level = "Z2"; obs_quality = [ "1", "2",
"9" ];
> },
> > > { name = "TMP"; level = "P500"; obs_quality = [ "1", "2"
]; }
> > > ];
> > > }
> > >
> > >
> > > Thanks,
> > > John
> > >
> >
> >
>
>
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: John Halley Gotway
Time: Tue Jul 02 10:01:39 2019
Binbin,
In my mind this issue is solved. The confusion was in using the PMO
observations and calling it PRMSL versus PB2NC deriving PRMSL from the
other obs types. What's the best practice here? Is using PMO
preferable
to deriving it? You can of course choose to do whatever you'd like,
but
this is a good detail to clarify because it'll impact your
verification
results.
FYI, I ran my sample gdas output through plot_point_obs and found:
PMO observations occur at 11441 locations.
Derived PRMSL observations occur at 17305 locations.
Those locations are shown in the attached plots.
Thanks,
John
On Tue, Jul 2, 2019 at 6:39 AM Binbin.Zhou at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
>
> John,
>
> Now you can read and copy, sorry about that.
>
> Binbin
>
> On Mon, Jul 1, 2019 at 5:08 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binbin,
> >
> > I went looking on theia this afternoon and found that the
permissions on
> > that prepbufr file are locked down:
> >
> > [John.H.Gotway at tfe02 g2o_ensemble_ADPSFC]$ ls -la
> >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> > -rw-r----- 1 Binbin.Zhou fv3-cam 78761312 Jun 26 18:54
> >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> >
> > I'm not in the fv3-cam group, so I'm not able to read it.
> >
> > John
> >
> > On Wed, Jun 26, 2019 at 1:15 PM Binbin.Zhou at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
> > >
> > > John,
> > >
> > > Thanks for further guideline for using obs_quality. It seems
> prepbufr
> > > has no problem.
> > > This issue only appears after 20190612. I have copied 20190623
12Z
> > prepbufr
> > > file to
> > > theia in
> > > directory
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
> > > The file name is gfs.t12z.prepbufr
> > >
> > > I used PB2NCConfig_gens.P(in the same directory) to test. In
this
> config
> > > file only PRMSL is specified.
> > > The resultant file is gfs.t12z.prebufr.f00.P.nc. From this file
you
> can
> > > see
> > > the QM marker is "NA".
> > >
> > > Binbin
> > >
> > > On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Binbin,
> > > >
> > > > I turned your email into a met-help question in case others on
our
> team
> > > > are able to help.
> > > >
> > > > Glad you've been able to make progress. But I don't
understand
> what's
> > > > going on with PRMSL. That observation does not actually exist
in the
> > > input
> > > > PREPBUFR file. Instead, it's derived from other
observations... just
> > > like
> > > > DPT, WDIR, WIND, RH, and MIXR are also derived from other obs.
> > > >
> > > > I reran PB2NC on a sample GDAS file from 20190612 (
> > > > gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the behavior
you
> > > > describe. I configured PB2NC to request all the native and
derived
> > > > variable types:
> > > >
> > > > obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB",
"D_DPT",
> > "D_WDIR",
> > > > "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
> > > >
> > > > Of the 36,913 PRMSL observations:
> > > > - 35,359 have QM = 9
> > > > - 205 have QM = 8
> > > > - 6 have QM = 6
> > > > - 323 have QM = 14
> > > > - 1020 have QM = 15
> > > >
> > > > But there are no observations with an NA quality marker. Do
you
> happen
> > > to
> > > > have the PREPBUFR file and PB2NC config file which produced
the NA
> > > quality
> > > > marker?
> > > >
> > > > One more detail. You do have the option of configuring which
quality
> > > > markers are used for each variable in the Point-Stat config
file.
> You
> > > just
> > > > define the obs_quality entry separately for each variable.
For
> > example,
> > > > use 1, 2, and 9 for 2-m temperature and only 1 and 2 for 500mb
> > > temperature:
> > > >
> > > > obs = {
> > > > field = [
> > > > { name = "TMP"; level = "Z2"; obs_quality = [ "1",
"2", "9"
> ];
> > },
> > > > { name = "TMP"; level = "P500"; obs_quality = [ "1", "2"
]; }
> > > > ];
> > > > }
> > > >
> > > >
> > > > Thanks,
> > > > John
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: 0-pair match issue in ensemble_stat
From: Binbin.Zhou at noaa.gov
Time: Tue Jul 02 12:16:17 2019
John,
Yes, I use PMO in PB2NC config file to convert PRMSL data from
prepbufr
to NetCDF.
Thanks for your further advice. Yes, this issue is solved.
Binbin
On Tue, Jul 2, 2019 at 12:01 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> In my mind this issue is solved. The confusion was in using the PMO
> observations and calling it PRMSL versus PB2NC deriving PRMSL from
the
> other obs types. What's the best practice here? Is using PMO
preferable
> to deriving it? You can of course choose to do whatever you'd like,
but
> this is a good detail to clarify because it'll impact your
verification
> results.
>
> FYI, I ran my sample gdas output through plot_point_obs and found:
> PMO observations occur at 11441 locations.
> Derived PRMSL observations occur at 17305 locations.
>
> Those locations are shown in the attached plots.
>
> Thanks,
> John
>
> On Tue, Jul 2, 2019 at 6:39 AM Binbin.Zhou at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808 >
> >
> > John,
> >
> > Now you can read and copy, sorry about that.
> >
> > Binbin
> >
> > On Mon, Jul 1, 2019 at 5:08 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binbin,
> > >
> > > I went looking on theia this afternoon and found that the
permissions
> on
> > > that prepbufr file are locked down:
> > >
> > > [John.H.Gotway at tfe02 g2o_ensemble_ADPSFC]$ ls -la
> > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> > > -rw-r----- 1 Binbin.Zhou fv3-cam 78761312 Jun 26 18:54
> > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC/gfs.t12z.prepbufr
> > >
> > > I'm not in the fv3-cam group, so I'm not able to read it.
> > >
> > > John
> > >
> > > On Wed, Jun 26, 2019 at 1:15 PM Binbin.Zhou at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=90808
>
> > > >
> > > > John,
> > > >
> > > > Thanks for further guideline for using obs_quality. It
seems
> > prepbufr
> > > > has no problem.
> > > > This issue only appears after 20190612. I have copied 20190623
12Z
> > > prepbufr
> > > > file to
> > > > theia in
> > > > directory
> > > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_ADPSFC
> > > > The file name is gfs.t12z.prepbufr
> > > >
> > > > I used PB2NCConfig_gens.P(in the same directory) to test. In
this
> > config
> > > > file only PRMSL is specified.
> > > > The resultant file is gfs.t12z.prebufr.f00.P.nc. From this
file you
> > can
> > > > see
> > > > the QM marker is "NA".
> > > >
> > > > Binbin
> > > >
> > > > On Wed, Jun 26, 2019 at 11:48 AM John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Binbin,
> > > > >
> > > > > I turned your email into a met-help question in case others
on our
> > team
> > > > > are able to help.
> > > > >
> > > > > Glad you've been able to make progress. But I don't
understand
> > what's
> > > > > going on with PRMSL. That observation does not actually
exist in
> the
> > > > input
> > > > > PREPBUFR file. Instead, it's derived from other
observations...
> just
> > > > like
> > > > > DPT, WDIR, WIND, RH, and MIXR are also derived from other
obs.
> > > > >
> > > > > I reran PB2NC on a sample GDAS file from 20190612 (
> > > > > gdas.20190612.t12z.prepbufr.nr) but I DO NOT see the
behavior you
> > > > > describe. I configured PB2NC to request all the native and
derived
> > > > > variable types:
> > > > >
> > > > > obs_bufr_var = [ "QOB", "TOB", "ZOB", "UOB", "VOB",
"D_DPT",
> > > "D_WDIR",
> > > > > "D_WIND", "D_RH", "D_MIXR", "D_PRMSL" ];
> > > > >
> > > > > Of the 36,913 PRMSL observations:
> > > > > - 35,359 have QM = 9
> > > > > - 205 have QM = 8
> > > > > - 6 have QM = 6
> > > > > - 323 have QM = 14
> > > > > - 1020 have QM = 15
> > > > >
> > > > > But there are no observations with an NA quality marker. Do
you
> > happen
> > > > to
> > > > > have the PREPBUFR file and PB2NC config file which produced
the NA
> > > > quality
> > > > > marker?
> > > > >
> > > > > One more detail. You do have the option of configuring
which
> quality
> > > > > markers are used for each variable in the Point-Stat config
file.
> > You
> > > > just
> > > > > define the obs_quality entry separately for each variable.
For
> > > example,
> > > > > use 1, 2, and 9 for 2-m temperature and only 1 and 2 for
500mb
> > > > temperature:
> > > > >
> > > > > obs = {
> > > > > field = [
> > > > > { name = "TMP"; level = "Z2"; obs_quality = [ "1",
"2", "9"
> > ];
> > > },
> > > > > { name = "TMP"; level = "P500"; obs_quality = [ "1",
"2" ]; }
> > > > > ];
> > > > > }
> > > > >
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list