[Met_help] [rt.rap.ucar.edu #99402] History for Help on using PB2NC and Point_stat

[John Halley Gotway via RT]

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

Hello, Would you help me?

I tried PB2NC using prebufr data stored in
/glade/collections/rda/data/ds337.0/prepnr/. METplus has successfully
finished running. See the log file of
/glade/scratch/zhuming/metplus4/logs/master_metplus.log.20210405090150

and

config file: /gpfs/fs1/work/zhuming/METplus4/PB2NC.conf


So I tried Point_stat using my created data from
/glade/scratch/zhuming/metplus4/pb2nc/pbs.2015071500.nc. But METplus has
successfully finished running with no matched pairs. See

the log file of

/glade/scratch/zhuming/metplus4/logs/master_metplus.log.20210405092244
and
config file: /gpfs/fs1/work/zhuming/METplus4/PointStat1.conf

Thanks,
Zhuming


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

Subject: Help on using PB2NC and Point_stat
From: John Halley Gotway
Time: Tue Apr 06 09:49:42 2021

Zhuming,

Short answer... you need to reconfigure/rerun pb2nc to retain more
observations.

Longer answer...

Thanks for sending us the path to your METplus log file. I see you're
getting 0 matched pairs from Point-Stat and are wondering why. There
are
many reasons why this could be happening but the log messages should
point
us in the right direction. I've copy/pasted some lines from the log
file
listing counts of reason codes for why the point observations were
discarded. The order of the log messages matches the order in which
the
filters are applied:

DEBUG 2: Processing T_2m(0,*,*) versus TMP/Z2, for observation type
ADPSFC,
over region FULL, for interpolation method BILIN(4), using 0 matched
pairs.
DEBUG 3: Number of matched pairs   = 0
DEBUG 3: Observations processed    = 723032
DEBUG 3: Rejected: station id      = 0
DEBUG 3: Rejected: obs var name    = 718878
DEBUG 3: Rejected: valid time      = 989
DEBUG 3: Rejected: bad obs value   = 0
DEBUG 3: Rejected: off the grid    = 2906
DEBUG 3: Rejected: topography      = 0
*DEBUG 3: Rejected: level mismatch  = 259*
DEBUG 3: Rejected: quality marker  = 0
DEBUG 3: Rejected: message type    = 0
DEBUG 3: Rejected: masking region  = 0
DEBUG 3: Rejected: bad fcst value  = 0
DEBUG 3: Rejected: bad climo mean  = 0
DEBUG 3: Rejected: bad climo stdev = 0
DEBUG 3: Rejected: duplicates      = 0

So looking from the bottom, up I see that 259 obs were discarded
because
their level value does not match what's requested in the config file.
But
notice that 0 observations survived to the "message type" filtering
step.
They were all discarded prior to that.

The same is true for the 10-m winds.

So I looked carefully in the input point observation file:
   /glade/scratch/zhuming/metplus4/pb2nc/pbs.2015071500.nc

And I ran MET's plot_point_obs tool to plot the point locations:
/glade/p/ral/jntp/MET/MET_releases/10.0.0-beta3/bin/plot_point_obs  \
/glade/scratch/zhuming/metplus4/pb2nc/pbs.2015071500.nc
pbs.2015071500.ps

Which eventually creates this image:
[image: Screen Shot 2021-04-06 at 9.03.04 AM.png]
But rerunning for only TMP and ADPSFC, plots 0 points:

*/glade/p/ral/jntp/MET/MET_releases/10.0.0-beta3/bin/plot_point_obs \*

*/glade/scratch/zhuming/metplus4/pb2nc/pbs.2015071500.nc
<http://pbs.2015071500.nc> pbs.2015071500.ps
<http://pbs.2015071500.ps>
-obs_var TMP -msg_typ ADPSFC*
*DEBUG 2: Finished plotting 0 locations.*

So the problem is that the output from PB2NC contains 0 observations
for
TMP at ADPSFC. So let's back up to that step.
You are using GDAS prepbufr observations:
PB2NC_INPUT_TEMPLATE =
{valid?fmt=%Y}/prepbufr.gdas.{valid?fmt=%Y%m%d%H}.nr

There's a rather annoying wrinkle to that data that's mentioned at the
bottom of this page:
http://dtcenter.org/community-code/model-evaluation-tools-met/input-
data

In order to retain observations of 2-m temperature and 10-m winds, you
need
to set the retain observations with a QC value of 9. By default, PB2NC
only
retains quality control values of 0, 1, and 2. So you need this in
your
PB2NC config file:
* quality_mark_thresh = 9;*

If the METplus 4.0 release were already available, you could do this
easily
by adding the following to PB2NC.conf:
* METPLUS_MET_CONFIG_OVERRIDES = quality_mark_thresh = 9;*

Since that's not available in beta3, you'll need to:
(1)
copy /glade/p/ral/jntp/MET/METplus/METplus-4.0.0-
beta3/parm/met_config/PB2NCConfig_wrapped
to a local area
(2) modify that file by replacing the "3" with the "9"
(3) edit PB2NC.conf by resetting the PB2NC_CONFIG_FILE entry to point
to
your custom config file.

Hope that helps!

Thanks,
John

On Mon, Apr 5, 2021 at 9:58 AM zhuming at ucar.edu via RT
<met_help at ucar.edu>
wrote:

>
> Mon Apr 05 09:58:21 2021: Request 99402 was acted upon.
> Transaction: Ticket created by zhuming at ucar.edu
>        Queue: met_help
>      Subject: Help on using PB2NC and Point_stat
>        Owner: Nobody
>   Requestors: zhuming at ucar.edu
>       Status: new
>  Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=99402 >
>
>
> Hello, Would you help me?
>
> I tried PB2NC using prebufr data stored in
> /glade/collections/rda/data/ds337.0/prepnr/. METplus has
successfully
> finished running. See the log file of
>
/glade/scratch/zhuming/metplus4/logs/master_metplus.log.20210405090150
>
> and
>
> config file: /gpfs/fs1/work/zhuming/METplus4/PB2NC.conf
>
>
> So I tried Point_stat using my created data from
> /glade/scratch/zhuming/metplus4/pb2nc/pbs.2015071500.nc. But METplus
has
> successfully finished running with no matched pairs. See
>
> the log file of
>
>
/glade/scratch/zhuming/metplus4/logs/master_metplus.log.20210405092244
> and
> config file: /gpfs/fs1/work/zhuming/METplus4/PointStat1.conf
>
> Thanks,
> Zhuming
>
>

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