[Met_help] [rt.rap.ucar.edu #94911] History for A question in CAPE verification
John Halley Gotway via RT
met_help at ucar.edu
Wed Apr 15 09:48:46 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I have a question about my CAPE verification:
The truth is prepbufr data. PC2NC tool was first used to derive
CAPE (D_CAPE), then use output nc file as truth, point-stat verify HREF
surface CAPE and some other surface variables forecast
(e.g. 2m T, DPT, WIND, CEILING, etc).
All other variables are fine, but CAPE has no output in the stat file.
The log message shows there is 0 pairs matches for CAPE.
I can not debug this issue further deep since I have no any other clue.
If you can provide help, please go to my testing directory on Venus
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test
and see the script file run.sh
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: A question in CAPE verification
From: John Halley Gotway
Time: Tue Apr 14 13:58:13 2020
Binbin,
Short answer...
CAPE is only derived from ADPUPA message types, not surface message
types (ADPSFC and SFCSHP). Edit this file:
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
By adding:
message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
Then rerun pb2nc and point-stat, using CAPE from ADPUPA message types.
I've added Perry Shafran as a CC on this ticket since he's been
verifying CAPE for regional models.
Longer answer...
Whenever you run Point-Stat and are wondering why you got 0 matched
pairs, it's a good idea to rerun the command with verbosity level 3 or
higher (-v 3). Doing that, I see the following log message related to
CAPE:
DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
ADPSFC, over region FULL, for interpolation method UW_MEAN_SQUARE(25),
using 0 matched pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 43733
DEBUG 3: Rejected: station id = 0
DEBUG 3: Rejected: obs type = 43733
...
You'll see that all the CAPE obs are rejected based on the "obs
type". So there just aren't any observations named CAPE in that file.
I ran ncdump to see the variable names listed in that file:
ncdump -v obs_var
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/prepda.2020041200.conus.nc
And CAPE does appear in that list of variable names:
obs_var =
"TMP",
"UGRD",
"VGRD",
"WIND",
"CAPE",
"PRMSL",
"VIS",
"TCDC",
"HGT",
"DPT" ;
}
CAPE is the 5th item in that list... so 0-based, it corresponds to a
variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
ncdump -v obs_vid
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/prepda.2020041200.conus.nc
| grep 4
So CAPE appears in the variable name list since you listed in the
PB2NC config file, but there aren't any actual CAPE observations
because they can only be derived for the ADPUPA message type.
Hope that helps explain the situation.
Thanks,
John
------------------------------------------------
Subject: A question in CAPE verification
From: Binbin.Zhou at noaa.gov
Time: Tue Apr 14 14:59:36 2020
John,
Thanks! I'll try.
Binbin
On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> Short answer...
>
> CAPE is only derived from ADPUPA message types, not surface message
types
> (ADPSFC and SFCSHP). Edit this file:
>
>
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>
> By adding:
> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>
> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>
> I've added Perry Shafran as a CC on this ticket since he's been
verifying
> CAPE for regional models.
>
> Longer answer...
>
> Whenever you run Point-Stat and are wondering why you got 0 matched
pairs,
> it's a good idea to rerun the command with verbosity level 3 or
higher (-v
> 3). Doing that, I see the following log message related to CAPE:
>
> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
ADPSFC,
> over region FULL, for interpolation method UW_MEAN_SQUARE(25), using
0
> matched pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 43733
> DEBUG 3: Rejected: station id = 0
> DEBUG 3: Rejected: obs type = 43733
> ...
>
> You'll see that all the CAPE obs are rejected based on the "obs
type". So
> there just aren't any observations named CAPE in that file.
>
> I ran ncdump to see the variable names listed in that file:
>
> ncdump -v obs_var
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
> prepda.2020041200.conus.nc
>
> And CAPE does appear in that list of variable names:
> obs_var =
> "TMP",
> "UGRD",
> "VGRD",
> "WIND",
> "CAPE",
> "PRMSL",
> "VIS",
> "TCDC",
> "HGT",
> "DPT" ;
> }
>
> CAPE is the 5th item in that list... so 0-based, it corresponds to a
> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>
> ncdump -v obs_vid
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
> prepda.2020041200.conus.nc | grep 4
>
> So CAPE appears in the variable name list since you listed in the
PB2NC
> config file, but there aren't any actual CAPE observations because
they can
> only be derived for the ADPUPA message type.
>
> Hope that helps explain the situation.
>
> Thanks,
> John
>
--
Binbin Zhou
IMSG at NOAA/NWS/NCEP/EMC
5830 University Research Ct.
College Park, MD 20740
Binbin.Zhou at noaa.gov
301-683-3683
------------------------------------------------
Subject: A question in CAPE verification
From: perry.shafran at noaa.gov
Time: Wed Apr 15 08:21:49 2020
Hi, Binbin,
Also you'll need to set this up in your METplus config file. Note
that the
obs level is L0-100000. John had told me that the 100000 part wasn't
necessary, but I noticed that I had to put that back in in order to
get
CAPE verification to work. I haven't checked though since we went to
METv9
or METplusv3 yet.
FCST_VAR11_NAME = CAPE
FCST_VAR11_LEVELS = L0
FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
OBS_VAR11_NAME = CAPE
OBS_VAR11_LEVELS = L0-100000
OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
Also set this up in your pb2nc config file.
obs_bufr_map = [
{ key = "HOVI"; val = "VIS"; },
{ key = "TOCC"; val = "TCDC"; },
{ key = "D_PBL"; val = "PBL"; },
{ key = "D_CAPE"; val = "CAPE"; },
{ key = "PMO"; val = "PRMSL"; },
{ key = "MXGS"; val = "GUST"; },
{ key = "TDO"; val = "DPT"; }
];
Thanks!
Perry
On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
binbin.zhou at noaa.gov> wrote:
> John,
>
> Thanks! I'll try.
>
> Binbin
>
> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Binbin,
>>
>> Short answer...
>>
>> CAPE is only derived from ADPUPA message types, not surface message
types
>> (ADPSFC and SFCSHP). Edit this file:
>>
>>
>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>
>> By adding:
>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>
>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>
>> I've added Perry Shafran as a CC on this ticket since he's been
verifying
>> CAPE for regional models.
>>
>> Longer answer...
>>
>> Whenever you run Point-Stat and are wondering why you got 0 matched
>> pairs, it's a good idea to rerun the command with verbosity level 3
or
>> higher (-v 3). Doing that, I see the following log message related
to CAPE:
>>
>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
ADPSFC,
>> over region FULL, for interpolation method UW_MEAN_SQUARE(25),
using 0
>> matched pairs.
>> DEBUG 3: Number of matched pairs = 0
>> DEBUG 3: Observations processed = 43733
>> DEBUG 3: Rejected: station id = 0
>> DEBUG 3: Rejected: obs type = 43733
>> ...
>>
>> You'll see that all the CAPE obs are rejected based on the "obs
type".
>> So there just aren't any observations named CAPE in that file.
>>
>> I ran ncdump to see the variable names listed in that file:
>>
>> ncdump -v obs_var
>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>> prepda.2020041200.conus.nc
>>
>> And CAPE does appear in that list of variable names:
>> obs_var =
>> "TMP",
>> "UGRD",
>> "VGRD",
>> "WIND",
>> "CAPE",
>> "PRMSL",
>> "VIS",
>> "TCDC",
>> "HGT",
>> "DPT" ;
>> }
>>
>> CAPE is the 5th item in that list... so 0-based, it corresponds to
a
>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>
>> ncdump -v obs_vid
>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>> prepda.2020041200.conus.nc | grep 4
>>
>> So CAPE appears in the variable name list since you listed in the
PB2NC
>> config file, but there aren't any actual CAPE observations because
they can
>> only be derived for the ADPUPA message type.
>>
>> Hope that helps explain the situation.
>>
>> Thanks,
>> John
>>
>
>
> --
>
> Binbin Zhou
>
> IMSG at NOAA/NWS/NCEP/EMC
>
> 5830 University Research Ct.
>
> College Park, MD 20740
>
> Binbin.Zhou at noaa.gov
>
> 301-683-3683
>
------------------------------------------------
Subject: A question in CAPE verification
From: Binbin.Zhou at noaa.gov
Time: Wed Apr 15 08:41:57 2020
John,
After adding "ADPUPA", the stat file has CAPE stats. This ticket can
be
closed.
Thanks again.
Binbin
On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> Short answer...
>
> CAPE is only derived from ADPUPA message types, not surface message
types
> (ADPSFC and SFCSHP). Edit this file:
>
>
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>
> By adding:
> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>
> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>
> I've added Perry Shafran as a CC on this ticket since he's been
verifying
> CAPE for regional models.
>
> Longer answer...
>
> Whenever you run Point-Stat and are wondering why you got 0 matched
pairs,
> it's a good idea to rerun the command with verbosity level 3 or
higher (-v
> 3). Doing that, I see the following log message related to CAPE:
>
> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
ADPSFC,
> over region FULL, for interpolation method UW_MEAN_SQUARE(25), using
0
> matched pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 43733
> DEBUG 3: Rejected: station id = 0
> DEBUG 3: Rejected: obs type = 43733
> ...
>
> You'll see that all the CAPE obs are rejected based on the "obs
type". So
> there just aren't any observations named CAPE in that file.
>
> I ran ncdump to see the variable names listed in that file:
>
> ncdump -v obs_var
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
> prepda.2020041200.conus.nc
>
> And CAPE does appear in that list of variable names:
> obs_var =
> "TMP",
> "UGRD",
> "VGRD",
> "WIND",
> "CAPE",
> "PRMSL",
> "VIS",
> "TCDC",
> "HGT",
> "DPT" ;
> }
>
> CAPE is the 5th item in that list... so 0-based, it corresponds to a
> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>
> ncdump -v obs_vid
>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
> prepda.2020041200.conus.nc | grep 4
>
> So CAPE appears in the variable name list since you listed in the
PB2NC
> config file, but there aren't any actual CAPE observations because
they can
> only be derived for the ADPUPA message type.
>
> Hope that helps explain the situation.
>
> Thanks,
> John
>
--
Binbin Zhou
IMSG at NOAA/NWS/NCEP/EMC
5830 University Research Ct.
College Park, MD 20740
Binbin.Zhou at noaa.gov
301-683-3683
------------------------------------------------
Subject: A question in CAPE verification
From: Binbin.Zhou at noaa.gov
Time: Wed Apr 15 09:17:03 2020
Perry,
Yes, all have been considered , except that
I use for fcst:
level = [ "L0" ];
desc = "surface";
Is this similar to
level = [ "L0-100000" ];
?
Or use
level = [ "L0-100000" ];
desc = "surface";
?
Binbin
On Wed, Apr 15, 2020 at 10:21 AM Perry Shafran - NOAA Affiliate <
perry.shafran at noaa.gov> wrote:
> Hi, Binbin,
>
> Also you'll need to set this up in your METplus config file. Note
that
> the obs level is L0-100000. John had told me that the 100000 part
wasn't
> necessary, but I noticed that I had to put that back in in order to
get
> CAPE verification to work. I haven't checked though since we went
to METv9
> or METplusv3 yet.
>
> FCST_VAR11_NAME = CAPE
> FCST_VAR11_LEVELS = L0
> FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
> FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
> OBS_VAR11_NAME = CAPE
> OBS_VAR11_LEVELS = L0-100000
> OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
> OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>
> Also set this up in your pb2nc config file.
>
> obs_bufr_map = [
> { key = "HOVI"; val = "VIS"; },
> { key = "TOCC"; val = "TCDC"; },
> { key = "D_PBL"; val = "PBL"; },
> { key = "D_CAPE"; val = "CAPE"; },
> { key = "PMO"; val = "PRMSL"; },
> { key = "MXGS"; val = "GUST"; },
> { key = "TDO"; val = "DPT"; }
> ];
>
> Thanks!
>
> Perry
>
> On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
> binbin.zhou at noaa.gov> wrote:
>
>> John,
>>
>> Thanks! I'll try.
>>
>> Binbin
>>
>> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>
>>> Binbin,
>>>
>>> Short answer...
>>>
>>> CAPE is only derived from ADPUPA message types, not surface
message
>>> types (ADPSFC and SFCSHP). Edit this file:
>>>
>>>
>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>>
>>> By adding:
>>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>>
>>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>>
>>> I've added Perry Shafran as a CC on this ticket since he's been
>>> verifying CAPE for regional models.
>>>
>>> Longer answer...
>>>
>>> Whenever you run Point-Stat and are wondering why you got 0
matched
>>> pairs, it's a good idea to rerun the command with verbosity level
3 or
>>> higher (-v 3). Doing that, I see the following log message
related to CAPE:
>>>
>>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
ADPSFC,
>>> over region FULL, for interpolation method UW_MEAN_SQUARE(25),
using 0
>>> matched pairs.
>>> DEBUG 3: Number of matched pairs = 0
>>> DEBUG 3: Observations processed = 43733
>>> DEBUG 3: Rejected: station id = 0
>>> DEBUG 3: Rejected: obs type = 43733
>>> ...
>>>
>>> You'll see that all the CAPE obs are rejected based on the "obs
type".
>>> So there just aren't any observations named CAPE in that file.
>>>
>>> I ran ncdump to see the variable names listed in that file:
>>>
>>> ncdump -v obs_var
>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>> prepda.2020041200.conus.nc
>>>
>>> And CAPE does appear in that list of variable names:
>>> obs_var =
>>> "TMP",
>>> "UGRD",
>>> "VGRD",
>>> "WIND",
>>> "CAPE",
>>> "PRMSL",
>>> "VIS",
>>> "TCDC",
>>> "HGT",
>>> "DPT" ;
>>> }
>>>
>>> CAPE is the 5th item in that list... so 0-based, it corresponds to
a
>>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>>
>>> ncdump -v obs_vid
>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>> prepda.2020041200.conus.nc | grep 4
>>>
>>> So CAPE appears in the variable name list since you listed in the
PB2NC
>>> config file, but there aren't any actual CAPE observations because
they can
>>> only be derived for the ADPUPA message type.
>>>
>>> Hope that helps explain the situation.
>>>
>>> Thanks,
>>> John
>>>
>>
>>
>> --
>>
>> Binbin Zhou
>>
>> IMSG at NOAA/NWS/NCEP/EMC
>>
>> 5830 University Research Ct.
>>
>> College Park, MD 20740
>>
>> Binbin.Zhou at noaa.gov
>>
>> 301-683-3683
>>
>
--
Binbin Zhou
IMSG at NOAA/NWS/NCEP/EMC
5830 University Research Ct.
College Park, MD 20740
Binbin.Zhou at noaa.gov
301-683-3683
------------------------------------------------
Subject: A question in CAPE verification
From: perry.shafran at noaa.gov
Time: Wed Apr 15 09:20:13 2020
Note that the L0-100000 designator is *only* for the observation. The
fcst
level should remain L0.
As far as I can tell, the desc identifier does nothing except merely
add
some text to your stat file to designate it as "surface" (in your
case).
Perry
On Wed, Apr 15, 2020 at 11:16 AM Binbin Zhou - NOAA Affiliate <
binbin.zhou at noaa.gov> wrote:
> Perry,
>
> Yes, all have been considered , except that
> I use for fcst:
> level = [ "L0" ];
> desc = "surface";
>
> Is this similar to
> level = [ "L0-100000" ];
> ?
>
> Or use
> level = [ "L0-100000" ];
> desc = "surface";
> ?
>
> Binbin
>
>
> On Wed, Apr 15, 2020 at 10:21 AM Perry Shafran - NOAA Affiliate <
> perry.shafran at noaa.gov> wrote:
>
>> Hi, Binbin,
>>
>> Also you'll need to set this up in your METplus config file. Note
that
>> the obs level is L0-100000. John had told me that the 100000 part
wasn't
>> necessary, but I noticed that I had to put that back in in order to
get
>> CAPE verification to work. I haven't checked though since we went
to METv9
>> or METplusv3 yet.
>>
>> FCST_VAR11_NAME = CAPE
>> FCST_VAR11_LEVELS = L0
>> FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
>> FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>> OBS_VAR11_NAME = CAPE
>> OBS_VAR11_LEVELS = L0-100000
>> OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
>> OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>
>> Also set this up in your pb2nc config file.
>>
>> obs_bufr_map = [
>> { key = "HOVI"; val = "VIS"; },
>> { key = "TOCC"; val = "TCDC"; },
>> { key = "D_PBL"; val = "PBL"; },
>> { key = "D_CAPE"; val = "CAPE"; },
>> { key = "PMO"; val = "PRMSL"; },
>> { key = "MXGS"; val = "GUST"; },
>> { key = "TDO"; val = "DPT"; }
>> ];
>>
>> Thanks!
>>
>> Perry
>>
>> On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
>> binbin.zhou at noaa.gov> wrote:
>>
>>> John,
>>>
>>> Thanks! I'll try.
>>>
>>> Binbin
>>>
>>> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Binbin,
>>>>
>>>> Short answer...
>>>>
>>>> CAPE is only derived from ADPUPA message types, not surface
message
>>>> types (ADPSFC and SFCSHP). Edit this file:
>>>>
>>>>
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>>>
>>>> By adding:
>>>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>>>
>>>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>>>
>>>> I've added Perry Shafran as a CC on this ticket since he's been
>>>> verifying CAPE for regional models.
>>>>
>>>> Longer answer...
>>>>
>>>> Whenever you run Point-Stat and are wondering why you got 0
matched
>>>> pairs, it's a good idea to rerun the command with verbosity level
3 or
>>>> higher (-v 3). Doing that, I see the following log message
related to CAPE:
>>>>
>>>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
>>>> ADPSFC, over region FULL, for interpolation method
UW_MEAN_SQUARE(25),
>>>> using 0 matched pairs.
>>>> DEBUG 3: Number of matched pairs = 0
>>>> DEBUG 3: Observations processed = 43733
>>>> DEBUG 3: Rejected: station id = 0
>>>> DEBUG 3: Rejected: obs type = 43733
>>>> ...
>>>>
>>>> You'll see that all the CAPE obs are rejected based on the "obs
type".
>>>> So there just aren't any observations named CAPE in that file.
>>>>
>>>> I ran ncdump to see the variable names listed in that file:
>>>>
>>>> ncdump -v obs_var
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>> prepda.2020041200.conus.nc
>>>>
>>>> And CAPE does appear in that list of variable names:
>>>> obs_var =
>>>> "TMP",
>>>> "UGRD",
>>>> "VGRD",
>>>> "WIND",
>>>> "CAPE",
>>>> "PRMSL",
>>>> "VIS",
>>>> "TCDC",
>>>> "HGT",
>>>> "DPT" ;
>>>> }
>>>>
>>>> CAPE is the 5th item in that list... so 0-based, it corresponds
to a
>>>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>>>
>>>> ncdump -v obs_vid
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>> prepda.2020041200.conus.nc | grep 4
>>>>
>>>> So CAPE appears in the variable name list since you listed in the
PB2NC
>>>> config file, but there aren't any actual CAPE observations
because they can
>>>> only be derived for the ADPUPA message type.
>>>>
>>>> Hope that helps explain the situation.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>
>>>
>>> --
>>>
>>> Binbin Zhou
>>>
>>> IMSG at NOAA/NWS/NCEP/EMC
>>>
>>> 5830 University Research Ct.
>>>
>>> College Park, MD 20740
>>>
>>> Binbin.Zhou at noaa.gov
>>>
>>> 301-683-3683
>>>
>>
>
> --
>
> Binbin Zhou
>
> IMSG at NOAA/NWS/NCEP/EMC
>
> 5830 University Research Ct.
>
> College Park, MD 20740
>
> Binbin.Zhou at noaa.gov
>
> 301-683-3683
>
------------------------------------------------
Subject: A question in CAPE verification
From: Binbin.Zhou at noaa.gov
Time: Wed Apr 15 09:21:05 2020
There are 3 CAPEs in HREF fcst files , but only the surface CAPE is
verified against observed CAPE. So I use desc = "surface" to
distinguished them.
Binbin
On Wed, Apr 15, 2020 at 11:16 AM Binbin Zhou - NOAA Affiliate <
binbin.zhou at noaa.gov> wrote:
> Perry,
>
> Yes, all have been considered , except that
> I use for fcst:
> level = [ "L0" ];
> desc = "surface";
>
> Is this similar to
> level = [ "L0-100000" ];
> ?
>
> Or use
> level = [ "L0-100000" ];
> desc = "surface";
> ?
>
> Binbin
>
>
> On Wed, Apr 15, 2020 at 10:21 AM Perry Shafran - NOAA Affiliate <
> perry.shafran at noaa.gov> wrote:
>
>> Hi, Binbin,
>>
>> Also you'll need to set this up in your METplus config file. Note
that
>> the obs level is L0-100000. John had told me that the 100000 part
wasn't
>> necessary, but I noticed that I had to put that back in in order to
get
>> CAPE verification to work. I haven't checked though since we went
to METv9
>> or METplusv3 yet.
>>
>> FCST_VAR11_NAME = CAPE
>> FCST_VAR11_LEVELS = L0
>> FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
>> FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>> OBS_VAR11_NAME = CAPE
>> OBS_VAR11_LEVELS = L0-100000
>> OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
>> OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>
>> Also set this up in your pb2nc config file.
>>
>> obs_bufr_map = [
>> { key = "HOVI"; val = "VIS"; },
>> { key = "TOCC"; val = "TCDC"; },
>> { key = "D_PBL"; val = "PBL"; },
>> { key = "D_CAPE"; val = "CAPE"; },
>> { key = "PMO"; val = "PRMSL"; },
>> { key = "MXGS"; val = "GUST"; },
>> { key = "TDO"; val = "DPT"; }
>> ];
>>
>> Thanks!
>>
>> Perry
>>
>> On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
>> binbin.zhou at noaa.gov> wrote:
>>
>>> John,
>>>
>>> Thanks! I'll try.
>>>
>>> Binbin
>>>
>>> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Binbin,
>>>>
>>>> Short answer...
>>>>
>>>> CAPE is only derived from ADPUPA message types, not surface
message
>>>> types (ADPSFC and SFCSHP). Edit this file:
>>>>
>>>>
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>>>
>>>> By adding:
>>>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>>>
>>>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>>>
>>>> I've added Perry Shafran as a CC on this ticket since he's been
>>>> verifying CAPE for regional models.
>>>>
>>>> Longer answer...
>>>>
>>>> Whenever you run Point-Stat and are wondering why you got 0
matched
>>>> pairs, it's a good idea to rerun the command with verbosity level
3 or
>>>> higher (-v 3). Doing that, I see the following log message
related to CAPE:
>>>>
>>>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
>>>> ADPSFC, over region FULL, for interpolation method
UW_MEAN_SQUARE(25),
>>>> using 0 matched pairs.
>>>> DEBUG 3: Number of matched pairs = 0
>>>> DEBUG 3: Observations processed = 43733
>>>> DEBUG 3: Rejected: station id = 0
>>>> DEBUG 3: Rejected: obs type = 43733
>>>> ...
>>>>
>>>> You'll see that all the CAPE obs are rejected based on the "obs
type".
>>>> So there just aren't any observations named CAPE in that file.
>>>>
>>>> I ran ncdump to see the variable names listed in that file:
>>>>
>>>> ncdump -v obs_var
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>> prepda.2020041200.conus.nc
>>>>
>>>> And CAPE does appear in that list of variable names:
>>>> obs_var =
>>>> "TMP",
>>>> "UGRD",
>>>> "VGRD",
>>>> "WIND",
>>>> "CAPE",
>>>> "PRMSL",
>>>> "VIS",
>>>> "TCDC",
>>>> "HGT",
>>>> "DPT" ;
>>>> }
>>>>
>>>> CAPE is the 5th item in that list... so 0-based, it corresponds
to a
>>>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>>>
>>>> ncdump -v obs_vid
>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>> prepda.2020041200.conus.nc | grep 4
>>>>
>>>> So CAPE appears in the variable name list since you listed in the
PB2NC
>>>> config file, but there aren't any actual CAPE observations
because they can
>>>> only be derived for the ADPUPA message type.
>>>>
>>>> Hope that helps explain the situation.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>
>>>
>>> --
>>>
>>> Binbin Zhou
>>>
>>> IMSG at NOAA/NWS/NCEP/EMC
>>>
>>> 5830 University Research Ct.
>>>
>>> College Park, MD 20740
>>>
>>> Binbin.Zhou at noaa.gov
>>>
>>> 301-683-3683
>>>
>>
>
> --
>
> Binbin Zhou
>
> IMSG at NOAA/NWS/NCEP/EMC
>
> 5830 University Research Ct.
>
> College Park, MD 20740
>
> Binbin.Zhou at noaa.gov
>
> 301-683-3683
>
--
Binbin Zhou
IMSG at NOAA/NWS/NCEP/EMC
5830 University Research Ct.
College Park, MD 20740
Binbin.Zhou at noaa.gov
301-683-3683
------------------------------------------------
Subject: A question in CAPE verification
From: perry.shafran at noaa.gov
Time: Wed Apr 15 09:36:47 2020
Yes, but that "desc" indicator doesn't affect the execution of the MET
code. That's only for information.
Perry
On Wed, Apr 15, 2020 at 11:21 AM Binbin Zhou - NOAA Affiliate <
binbin.zhou at noaa.gov> wrote:
> There are 3 CAPEs in HREF fcst files , but only the surface CAPE is
> verified against observed CAPE. So I use desc = "surface" to
> distinguished them.
>
> Binbin
>
> On Wed, Apr 15, 2020 at 11:16 AM Binbin Zhou - NOAA Affiliate <
> binbin.zhou at noaa.gov> wrote:
>
>> Perry,
>>
>> Yes, all have been considered , except that
>> I use for fcst:
>> level = [ "L0" ];
>> desc = "surface";
>>
>> Is this similar to
>> level = [ "L0-100000" ];
>> ?
>>
>> Or use
>> level = [ "L0-100000" ];
>> desc = "surface";
>> ?
>>
>> Binbin
>>
>>
>> On Wed, Apr 15, 2020 at 10:21 AM Perry Shafran - NOAA Affiliate <
>> perry.shafran at noaa.gov> wrote:
>>
>>> Hi, Binbin,
>>>
>>> Also you'll need to set this up in your METplus config file. Note
that
>>> the obs level is L0-100000. John had told me that the 100000 part
wasn't
>>> necessary, but I noticed that I had to put that back in in order
to get
>>> CAPE verification to work. I haven't checked though since we went
to METv9
>>> or METplusv3 yet.
>>>
>>> FCST_VAR11_NAME = CAPE
>>> FCST_VAR11_LEVELS = L0
>>> FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
>>> FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>> OBS_VAR11_NAME = CAPE
>>> OBS_VAR11_LEVELS = L0-100000
>>> OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
>>> OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>>
>>> Also set this up in your pb2nc config file.
>>>
>>> obs_bufr_map = [
>>> { key = "HOVI"; val = "VIS"; },
>>> { key = "TOCC"; val = "TCDC"; },
>>> { key = "D_PBL"; val = "PBL"; },
>>> { key = "D_CAPE"; val = "CAPE"; },
>>> { key = "PMO"; val = "PRMSL"; },
>>> { key = "MXGS"; val = "GUST"; },
>>> { key = "TDO"; val = "DPT"; }
>>> ];
>>>
>>> Thanks!
>>>
>>> Perry
>>>
>>> On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
>>> binbin.zhou at noaa.gov> wrote:
>>>
>>>> John,
>>>>
>>>> Thanks! I'll try.
>>>>
>>>> Binbin
>>>>
>>>> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> Binbin,
>>>>>
>>>>> Short answer...
>>>>>
>>>>> CAPE is only derived from ADPUPA message types, not surface
message
>>>>> types (ADPSFC and SFCSHP). Edit this file:
>>>>>
>>>>>
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>>>>
>>>>> By adding:
>>>>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>>>>
>>>>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>>>>
>>>>> I've added Perry Shafran as a CC on this ticket since he's been
>>>>> verifying CAPE for regional models.
>>>>>
>>>>> Longer answer...
>>>>>
>>>>> Whenever you run Point-Stat and are wondering why you got 0
matched
>>>>> pairs, it's a good idea to rerun the command with verbosity
level 3 or
>>>>> higher (-v 3). Doing that, I see the following log message
related to CAPE:
>>>>>
>>>>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
>>>>> ADPSFC, over region FULL, for interpolation method
UW_MEAN_SQUARE(25),
>>>>> using 0 matched pairs.
>>>>> DEBUG 3: Number of matched pairs = 0
>>>>> DEBUG 3: Observations processed = 43733
>>>>> DEBUG 3: Rejected: station id = 0
>>>>> DEBUG 3: Rejected: obs type = 43733
>>>>> ...
>>>>>
>>>>> You'll see that all the CAPE obs are rejected based on the "obs
>>>>> type". So there just aren't any observations named CAPE in that
file.
>>>>>
>>>>> I ran ncdump to see the variable names listed in that file:
>>>>>
>>>>> ncdump -v obs_var
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>>> prepda.2020041200.conus.nc
>>>>>
>>>>> And CAPE does appear in that list of variable names:
>>>>> obs_var =
>>>>> "TMP",
>>>>> "UGRD",
>>>>> "VGRD",
>>>>> "WIND",
>>>>> "CAPE",
>>>>> "PRMSL",
>>>>> "VIS",
>>>>> "TCDC",
>>>>> "HGT",
>>>>> "DPT" ;
>>>>> }
>>>>>
>>>>> CAPE is the 5th item in that list... so 0-based, it corresponds
to a
>>>>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>>>>
>>>>> ncdump -v obs_vid
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>>> prepda.2020041200.conus.nc | grep 4
>>>>>
>>>>> So CAPE appears in the variable name list since you listed in
the
>>>>> PB2NC config file, but there aren't any actual CAPE observations
because
>>>>> they can only be derived for the ADPUPA message type.
>>>>>
>>>>> Hope that helps explain the situation.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Binbin Zhou
>>>>
>>>> IMSG at NOAA/NWS/NCEP/EMC
>>>>
>>>> 5830 University Research Ct.
>>>>
>>>> College Park, MD 20740
>>>>
>>>> Binbin.Zhou at noaa.gov
>>>>
>>>> 301-683-3683
>>>>
>>>
>>
>> --
>>
>> Binbin Zhou
>>
>> IMSG at NOAA/NWS/NCEP/EMC
>>
>> 5830 University Research Ct.
>>
>> College Park, MD 20740
>>
>> Binbin.Zhou at noaa.gov
>>
>> 301-683-3683
>>
>
>
> --
>
> Binbin Zhou
>
> IMSG at NOAA/NWS/NCEP/EMC
>
> 5830 University Research Ct.
>
> College Park, MD 20740
>
> Binbin.Zhou at noaa.gov
>
> 301-683-3683
>
------------------------------------------------
Subject: A question in CAPE verification
From: Binbin.Zhou at noaa.gov
Time: Wed Apr 15 09:37:36 2020
I just tested and found
level = [ "L0" ];
desc = "surface";
and
level = [ "L0-100000" ];
are same
Binbin
On Wed, Apr 15, 2020 at 11:20 AM Binbin Zhou - NOAA Affiliate <
binbin.zhou at noaa.gov> wrote:
> There are 3 CAPEs in HREF fcst files , but only the surface CAPE is
> verified against observed CAPE. So I use desc = "surface" to
> distinguished them.
>
> Binbin
>
> On Wed, Apr 15, 2020 at 11:16 AM Binbin Zhou - NOAA Affiliate <
> binbin.zhou at noaa.gov> wrote:
>
>> Perry,
>>
>> Yes, all have been considered , except that
>> I use for fcst:
>> level = [ "L0" ];
>> desc = "surface";
>>
>> Is this similar to
>> level = [ "L0-100000" ];
>> ?
>>
>> Or use
>> level = [ "L0-100000" ];
>> desc = "surface";
>> ?
>>
>> Binbin
>>
>>
>> On Wed, Apr 15, 2020 at 10:21 AM Perry Shafran - NOAA Affiliate <
>> perry.shafran at noaa.gov> wrote:
>>
>>> Hi, Binbin,
>>>
>>> Also you'll need to set this up in your METplus config file. Note
that
>>> the obs level is L0-100000. John had told me that the 100000 part
wasn't
>>> necessary, but I noticed that I had to put that back in in order
to get
>>> CAPE verification to work. I haven't checked though since we went
to METv9
>>> or METplusv3 yet.
>>>
>>> FCST_VAR11_NAME = CAPE
>>> FCST_VAR11_LEVELS = L0
>>> FCST_VAR11_OPTIONS = cnt_thresh = [ >0 ];
>>> FCST_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>> OBS_VAR11_NAME = CAPE
>>> OBS_VAR11_LEVELS = L0-100000
>>> OBS_VAR11_OPTIONS = cnt_thresh = [ >0 ]; cnt_logic = UNION;
>>> OBS_VAR11_THRESH = >500, >1000, >1500, >2000, >3000, >4000
>>>
>>> Also set this up in your pb2nc config file.
>>>
>>> obs_bufr_map = [
>>> { key = "HOVI"; val = "VIS"; },
>>> { key = "TOCC"; val = "TCDC"; },
>>> { key = "D_PBL"; val = "PBL"; },
>>> { key = "D_CAPE"; val = "CAPE"; },
>>> { key = "PMO"; val = "PRMSL"; },
>>> { key = "MXGS"; val = "GUST"; },
>>> { key = "TDO"; val = "DPT"; }
>>> ];
>>>
>>> Thanks!
>>>
>>> Perry
>>>
>>> On Tue, Apr 14, 2020 at 4:59 PM Binbin Zhou - NOAA Affiliate <
>>> binbin.zhou at noaa.gov> wrote:
>>>
>>>> John,
>>>>
>>>> Thanks! I'll try.
>>>>
>>>> Binbin
>>>>
>>>> On Tue, Apr 14, 2020 at 3:58 PM John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>
>>>>> Binbin,
>>>>>
>>>>> Short answer...
>>>>>
>>>>> CAPE is only derived from ADPUPA message types, not surface
message
>>>>> types (ADPSFC and SFCSHP). Edit this file:
>>>>>
>>>>>
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/PB2NCConfig_HREF_conus
>>>>>
>>>>> By adding:
>>>>> message_type = ["ADPUPA", "ADPSFC", "SFCSHP"];
>>>>>
>>>>> Then rerun pb2nc and point-stat, using CAPE from ADPUPA message
types.
>>>>>
>>>>> I've added Perry Shafran as a CC on this ticket since he's been
>>>>> verifying CAPE for regional models.
>>>>>
>>>>> Longer answer...
>>>>>
>>>>> Whenever you run Point-Stat and are wondering why you got 0
matched
>>>>> pairs, it's a good idea to rerun the command with verbosity
level 3 or
>>>>> higher (-v 3). Doing that, I see the following log message
related to CAPE:
>>>>>
>>>>> DEBUG 2: Processing CAPE/L0 versus CAPE/L0, for observation type
>>>>> ADPSFC, over region FULL, for interpolation method
UW_MEAN_SQUARE(25),
>>>>> using 0 matched pairs.
>>>>> DEBUG 3: Number of matched pairs = 0
>>>>> DEBUG 3: Observations processed = 43733
>>>>> DEBUG 3: Rejected: station id = 0
>>>>> DEBUG 3: Rejected: obs type = 43733
>>>>> ...
>>>>>
>>>>> You'll see that all the CAPE obs are rejected based on the "obs
>>>>> type". So there just aren't any observations named CAPE in that
file.
>>>>>
>>>>> I ran ncdump to see the variable names listed in that file:
>>>>>
>>>>> ncdump -v obs_var
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>>> prepda.2020041200.conus.nc
>>>>>
>>>>> And CAPE does appear in that list of variable names:
>>>>> obs_var =
>>>>> "TMP",
>>>>> "UGRD",
>>>>> "VGRD",
>>>>> "WIND",
>>>>> "CAPE",
>>>>> "PRMSL",
>>>>> "VIS",
>>>>> "TCDC",
>>>>> "HGT",
>>>>> "DPT" ;
>>>>> }
>>>>>
>>>>> CAPE is the 5th item in that list... so 0-based, it corresponds
to a
>>>>> variable id = 4. But 4 doesn't actually appear in the obs_vid
variable:
>>>>>
>>>>> ncdump -v obs_vid
>>>>>
/gpfs/dell2/emc/modeling/noscrub/Binbin.Zhou/usr2/MET/stat/hrefsclr/sfc/test/
>>>>> prepda.2020041200.conus.nc | grep 4
>>>>>
>>>>> So CAPE appears in the variable name list since you listed in
the
>>>>> PB2NC config file, but there aren't any actual CAPE observations
because
>>>>> they can only be derived for the ADPUPA message type.
>>>>>
>>>>> Hope that helps explain the situation.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Binbin Zhou
>>>>
>>>> IMSG at NOAA/NWS/NCEP/EMC
>>>>
>>>> 5830 University Research Ct.
>>>>
>>>> College Park, MD 20740
>>>>
>>>> Binbin.Zhou at noaa.gov
>>>>
>>>> 301-683-3683
>>>>
>>>
>>
>> --
>>
>> Binbin Zhou
>>
>> IMSG at NOAA/NWS/NCEP/EMC
>>
>> 5830 University Research Ct.
>>
>> College Park, MD 20740
>>
>> Binbin.Zhou at noaa.gov
>>
>> 301-683-3683
>>
>
>
> --
>
> Binbin Zhou
>
> IMSG at NOAA/NWS/NCEP/EMC
>
> 5830 University Research Ct.
>
> College Park, MD 20740
>
> Binbin.Zhou at noaa.gov
>
> 301-683-3683
>
--
Binbin Zhou
IMSG at NOAA/NWS/NCEP/EMC
5830 University Research Ct.
College Park, MD 20740
Binbin.Zhou at noaa.gov
301-683-3683
------------------------------------------------
More information about the Met_help
mailing list