[Met_help] [rt.rap.ucar.edu #88718] History for SSVAR Output Question
John Halley Gotway via RT
met_help at ucar.edu
Fri Feb 1 13:48:00 MST 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I'm running ensemble_stat on an ensemble of 63 members. I'm looking at the SSVAR output but I'm confused by what I'm seeing.
For a 240-hour global surface temperature forecast, I get 112 bins. The highest one is 125-126, in units of degrees Kelvin squared. I used a bin width of 1 K.
When I subset to the northern hemisphere only, I get 4,148 bins. The highest one is 4927-4928 Kelvin^2.
When I subset to the southern hemisphere only, I get 3,627 bins. The highest one is 4176-4177 Kelvin^2.
Why do I have more bins when I subset the full globe into two hemispheres? Shouldn't the values of the variances be between 0-126 K^2, just as they were for the whole globe? How did they suddenly get so much larger? Subsetting shouldn't change the original values.
Below is the full config file that is being sourced. I don't see anything obvious that I'm doing wrong.
Thanks,
Matt
//
// Output model name to be written
//
model = "GEPS";
//
// Output description to be written
// May be set separately in each "obs.field" entry
//
desc = "NA";
//
// Output observation type to be written
//
obtype = "ANALYS";
////////////////////////////////////////////////////////////////////////////////
//
// Verification grid
//
regrid = {
to_grid = FCST;
method = NEAREST;
width = 1;
vld_thresh = 1.0;
shape = SQUARE;
}
////////////////////////////////////////////////////////////////////////////////
//
// May be set separately in each "field" entry
//
censor_thresh = [];
censor_val = [];
cat_thresh = [];
//
// Ensemble product fields to be processed
//
ens = {
ens_thresh = 1.0;
vld_thresh = 1.0;
field = [
{ name = "TMP"; level = "Z2"; },
{ name = "TMP"; level = "P850"; },
{ name = "WIND"; level = "Z10"; },
{ name = "WIND"; level = "P850"; },
{ name = "WIND"; level = "P250"; },
{ name = "HGT"; level = "P700"; },
{ name = "HGT"; level = "P500"; },
{ name = "RH"; level = "P700"; },
{ name = "PRMSL"; level = "A0"; }
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Forecast and observation fields to be verified
//
fcst = {
file_type = GRIB2;
field = [
{ name = "TMP"; level = "Z2"; ens_ssvar_bin_size = 1.0;},
{ name = "TMP"; level = "P850"; ens_ssvar_bin_size = 1.0;},
{ name = "WIND"; level = "Z10"; ens_ssvar_bin_size = 1.0;},
{ name = "WIND"; level = "P850"; ens_ssvar_bin_size = 1.0;},
{ name = "WIND"; level = "P250"; ens_ssvar_bin_size = 1.0;},
{ name = "HGT"; level = "P700"; ens_ssvar_bin_size = 25.0;},
{ name = "HGT"; level = "P500"; ens_ssvar_bin_size = 25.0;},
{ name = "RH"; level = "P700"; ens_ssvar_bin_size = 5.0;},
{ name = "PRMSL"; level = "A0"; ens_ssvar_bin_size = 100.0;}
];
}
obs = fcst;
////////////////////////////////////////////////////////////////////////////////
//
// Point observation filtering options
// May be set separately in each "obs.field" entry
//
message_type = [];
sid_exc = [];
obs_thresh = [ NA ];
obs_quality = [];
duplicate_flag = NONE;
obs_summary = NONE;
obs_perc_value = 50;
skip_const = FALSE;
ens_phist_bin_size = 0.05;
////////////////////////////////////////////////////////////////////////////////
//
// Climatology mean data
//
climo_mean = {
file_name = [];
field = [];
regrid = {
method = NEAREST;
width = 1;
vld_thresh = 0.5;
shape = SQUARE;
}
time_interp_method = DW_MEAN;
match_day = FALSE;
time_step = 21600;
}
////////////////////////////////////////////////////////////////////////////////
//
// Point observation time window
//
obs_window = {
beg = -5400;
end = 5400;
}
////////////////////////////////////////////////////////////////////////////////
//
// Verification masking regions
//
mask = {
grid = [ "FULL" ];
poly = [ "${POLY_DIR}/NHEM_mask.nc",
"${POLY_DIR}/SHEM_mask.nc",
"${POLY_DIR}/20N20S_mask.nc",
"${POLY_DIR}/20N80N_mask.nc",
"${POLY_DIR}/20S80S_mask.nc" ];
sid = [];
}
////////////////////////////////////////////////////////////////////////////////
//
// Confidence interval settings
//
ci_alpha = [ 0.05 ];
////////////////////////////////////////////////////////////////////////////////
//
// Interpolation methods
//
interp = {
field = BOTH;
vld_thresh = 1.0;
shape = SQUARE;
type = [
{
method = NEAREST;
width = 1;
}
];
}
////////////////////////////////////////////////////////////////////////////////
//
// Statistical output types
//
output_flag = {
rhist = BOTH;
phist = NONE;
orank = NONE;
ssvar = BOTH;
relp = NONE;
}
//
// Ensemble product output types
//
ensemble_flag = {
mean = TRUE;
stdev = TRUE;
minus = FALSE;
plus = FALSE;
min = FALSE;
max = FALSE;
range = FALSE;
vld_count = FALSE;
frequency = FALSE;
rank = FALSE;
weight = FALSE;
}
////////////////////////////////////////////////////////////////////////////////
//
// Random number generator
//
rng = {
type = "mt19937";
seed = "";
}
////////////////////////////////////////////////////////////////////////////////
grid_weight_flag = NONE;
output_prefix = "GEPS_ALL";
obs_quality = [];
version = "V6.1";
Matthew C. Sittel, Meteorologist
University Corporation for Atmospheric Research
Matthew.Sittel.ctr at us.af.mil
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Thu Jan 31 11:00:09 2019
Matt,
Yes, I agree. The *variance* is computed across the ensemble members
for
each grid point. And the computed variance values should be
independent of
the masking regions... FULL globe or separate hemispheres.
The fact that you're seeing different maximum variance values
depending on
the masking regions seems suspicious.
I'll try to replicate that behavior here.
Thanks,
John
On Thu, Jan 31, 2019 at 9:27 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
via RT <met_help at ucar.edu> wrote:
>
> Thu Jan 31 09:26:53 2019: Request 88718 was acted upon.
> Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> Queue: met_help
> Subject: SSVAR Output Question
> Owner: Nobody
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
>
> Hi,
>
> I'm running ensemble_stat on an ensemble of 63 members. I'm looking
at
> the SSVAR output but I'm confused by what I'm seeing.
>
> For a 240-hour global surface temperature forecast, I get 112 bins.
The
> highest one is 125-126, in units of degrees Kelvin squared. I used
a bin
> width of 1 K.
>
> When I subset to the northern hemisphere only, I get 4,148 bins.
The
> highest one is 4927-4928 Kelvin^2.
>
> When I subset to the southern hemisphere only, I get 3,627 bins.
The
> highest one is 4176-4177 Kelvin^2.
>
> Why do I have more bins when I subset the full globe into two
> hemispheres? Shouldn't the values of the variances be between 0-126
K^2,
> just as they were for the whole globe? How did they suddenly get so
much
> larger? Subsetting shouldn't change the original values.
>
> Below is the full config file that is being sourced. I don't see
anything
> obvious that I'm doing wrong.
>
> Thanks,
> Matt
>
> //
> // Output model name to be written
> //
> model = "GEPS";
>
> //
> // Output description to be written
> // May be set separately in each "obs.field" entry
> //
> desc = "NA";
>
> //
> // Output observation type to be written
> //
> obtype = "ANALYS";
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Verification grid
> //
> regrid = {
> to_grid = FCST;
> method = NEAREST;
> width = 1;
> vld_thresh = 1.0;
> shape = SQUARE;
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // May be set separately in each "field" entry
> //
> censor_thresh = [];
> censor_val = [];
> cat_thresh = [];
>
> //
> // Ensemble product fields to be processed
> //
> ens = {
> ens_thresh = 1.0;
> vld_thresh = 1.0;
>
> field = [
> { name = "TMP"; level = "Z2"; },
> { name = "TMP"; level = "P850"; },
> { name = "WIND"; level = "Z10"; },
> { name = "WIND"; level = "P850"; },
> { name = "WIND"; level = "P250"; },
> { name = "HGT"; level = "P700"; },
> { name = "HGT"; level = "P500"; },
> { name = "RH"; level = "P700"; },
> { name = "PRMSL"; level = "A0"; }
> ];
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Forecast and observation fields to be verified
> //
> fcst = {
> file_type = GRIB2;
>
> field = [
> { name = "TMP"; level = "Z2"; ens_ssvar_bin_size = 1.0;},
> { name = "TMP"; level = "P850"; ens_ssvar_bin_size = 1.0;},
> { name = "WIND"; level = "Z10"; ens_ssvar_bin_size = 1.0;},
> { name = "WIND"; level = "P850"; ens_ssvar_bin_size = 1.0;},
> { name = "WIND"; level = "P250"; ens_ssvar_bin_size = 1.0;},
> { name = "HGT"; level = "P700"; ens_ssvar_bin_size = 25.0;},
> { name = "HGT"; level = "P500"; ens_ssvar_bin_size = 25.0;},
> { name = "RH"; level = "P700"; ens_ssvar_bin_size = 5.0;},
> { name = "PRMSL"; level = "A0"; ens_ssvar_bin_size = 100.0;}
> ];
> }
>
> obs = fcst;
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Point observation filtering options
> // May be set separately in each "obs.field" entry
> //
> message_type = [];
> sid_exc = [];
> obs_thresh = [ NA ];
> obs_quality = [];
> duplicate_flag = NONE;
> obs_summary = NONE;
> obs_perc_value = 50;
> skip_const = FALSE;
> ens_phist_bin_size = 0.05;
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Climatology mean data
> //
> climo_mean = {
>
> file_name = [];
> field = [];
>
> regrid = {
> method = NEAREST;
> width = 1;
> vld_thresh = 0.5;
> shape = SQUARE;
> }
>
> time_interp_method = DW_MEAN;
> match_day = FALSE;
> time_step = 21600;
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Point observation time window
> //
> obs_window = {
> beg = -5400;
> end = 5400;
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Verification masking regions
> //
> mask = {
> grid = [ "FULL" ];
> poly = [ "${POLY_DIR}/NHEM_mask.nc",
> "${POLY_DIR}/SHEM_mask.nc",
> "${POLY_DIR}/20N20S_mask.nc",
> "${POLY_DIR}/20N80N_mask.nc",
> "${POLY_DIR}/20S80S_mask.nc" ];
> sid = [];
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Confidence interval settings
> //
> ci_alpha = [ 0.05 ];
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Interpolation methods
> //
> interp = {
> field = BOTH;
> vld_thresh = 1.0;
> shape = SQUARE;
>
> type = [
> {
> method = NEAREST;
> width = 1;
> }
> ];
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Statistical output types
> //
> output_flag = {
> rhist = BOTH;
> phist = NONE;
> orank = NONE;
> ssvar = BOTH;
> relp = NONE;
> }
>
> //
> // Ensemble product output types
> //
> ensemble_flag = {
> mean = TRUE;
> stdev = TRUE;
> minus = FALSE;
> plus = FALSE;
> min = FALSE;
> max = FALSE;
> range = FALSE;
> vld_count = FALSE;
> frequency = FALSE;
> rank = FALSE;
> weight = FALSE;
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Random number generator
> //
> rng = {
> type = "mt19937";
> seed = "";
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> grid_weight_flag = NONE;
> output_prefix = "GEPS_ALL";
> obs_quality = [];
> version = "V6.1";
>
> Matthew C. Sittel, Meteorologist
> University Corporation for Atmospheric Research
> Matthew.Sittel.ctr at us.af.mil
>
>
>
------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Thu Jan 31 11:40:36 2019
Matt,
I did some more testing and want to make sure I'm looking at the data
in
the same way you are.
I grabbed 6 members of GEFS from this site:
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/00/pgrb2/
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-meter
temperature to an "observation" of the the first member. Not really
valid
scientifically, but good enough for software testing:
*/usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
\EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
And I'm computing SSVAR over the *FULL* globe, the Norther Hemisphere
(*NH*),
and the southern hemisphere (*SH*). Below, I've pasted the relevant
columns from the *last *SSVAR line for each of these regions:
*foreach STR (`echo "VERSION FULL NH SH"`)*
* grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1 |
awk
'{print $15, $22, $24, $25, $27, $28}'*
*end*
VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
FULL SSVAR 217 216 223 224
NH SSVAR 217 216 223 224
SH SSVAR 78 77 77 78
The maximum variance bin for the FULL globe has endpoints of 223 and
224.
The maximum must occur in the NH, because it has the same maximum
variance
bin. In the SH, the maximum variance bin is 77 to 78. This output
makes
sense to me, and I don't see any problems.
Are you interpreting the output the same way... checking to see how
the
VAR_MIN and VAR_MAX columns vary across the different masking regions?
Thanks,
John
On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
met_help at ucar.edu> wrote:
>
> Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
> Queue: met_help
> Subject: SSVAR Output Question
> Owner: johnhg
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: robert.craig.2 at us.af.mil
Time: Thu Jan 31 11:49:45 2019
John, Matt is out this afternoon but will be in tomorrow. As an
aside, we did some testing of ARL SAFE where I sent a file to my home
email address. My email address should not be any different then
met_help as far as the system is concerned. I received an email from
ARL Safe with the link. I clicked the link and initially got an error
that I didn't have a valid certificate. I clicked cancel and the
subsequent screen that came up had more information on the error but
had a link at the very bottom to return to ARL Safe. When I clicked
this then it should the files I had been sent. Are you getting the
initial email in met_help? Should we be sending it directly to you
instead?
Bob
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Thursday, January 31, 2019 12:41 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
Question
Matt,
I did some more testing and want to make sure I'm looking at the data
in the same way you are.
I grabbed 6 members of GEFS from this site:
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/00/pgrb2/
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-meter
temperature to an "observation" of the the first member. Not really
valid scientifically, but good enough for software testing:
*/usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
\EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
And I'm computing SSVAR over the *FULL* globe, the Norther Hemisphere
(*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
relevant columns from the *last *SSVAR line for each of these regions:
*foreach STR (`echo "VERSION FULL NH SH"`)*
* grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1 |
awk '{print $15, $22, $24, $25, $27, $28}'*
*end*
VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
FULL SSVAR 217 216 223 224
NH SSVAR 217 216 223 224
SH SSVAR 78 77 77 78
The maximum variance bin for the FULL globe has endpoints of 223 and
224.
The maximum must occur in the NH, because it has the same maximum
variance bin. In the SH, the maximum variance bin is 77 to 78. This
output makes sense to me, and I don't see any problems.
Are you interpreting the output the same way... checking to see how
the VAR_MIN and VAR_MAX columns vary across the different masking
regions?
Thanks,
John
On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
met_help at ucar.edu> wrote:
>
> Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
> Queue: met_help
> Subject: SSVAR Output Question
> Owner: johnhg
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Thu Jan 31 12:05:53 2019
Bob,
No, I am not receiving any ARL SAFE emails. Perhaps it's being
filtered
out by email filters at NCAR? I'm not sure.
You can definitely try sending it to johnhg at ucar.edu instead.
John
On Thu, Jan 31, 2019 at 11:50 AM robert.craig.2 at us.af.mil via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> John, Matt is out this afternoon but will be in tomorrow. As an
aside, we
> did some testing of ARL SAFE where I sent a file to my home email
address.
> My email address should not be any different then met_help as far as
the
> system is concerned. I received an email from ARL Safe with the
link. I
> clicked the link and initially got an error that I didn't have a
valid
> certificate. I clicked cancel and the subsequent screen that came
up had
> more information on the error but had a link at the very bottom to
return
> to ARL Safe. When I clicked this then it should the files I had
been
> sent. Are you getting the initial email in met_help? Should we be
sending
> it directly to you instead?
>
> Bob
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 12:41 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
> Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
> Question
>
> Matt,
>
> I did some more testing and want to make sure I'm looking at the
data in
> the same way you are.
>
> I grabbed 6 members of GEFS from this site:
>
>
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/00/pgrb2/
>
>
>
>
>
>
>
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
>
> I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> temperature to an "observation" of the the first member. Not really
valid
> scientifically, but good enough for software testing:
>
>
>
>
>
> */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
>
> And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> (*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
> relevant columns from the *last *SSVAR line for each of these
regions:
>
> *foreach STR (`echo "VERSION FULL NH SH"`)*
>
> * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1
| awk
> '{print $15, $22, $24, $25, $27, $28}'*
> *end*
>
> VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> FULL SSVAR 217 216 223 224
> NH SSVAR 217 216 223 224
> SH SSVAR 78 77 77 78
>
> The maximum variance bin for the FULL globe has endpoints of 223 and
224.
> The maximum must occur in the NH, because it has the same maximum
variance
> bin. In the SH, the maximum variance bin is 77 to 78. This output
makes
> sense to me, and I don't see any problems.
>
> Are you interpreting the output the same way... checking to see how
the
> VAR_MIN and VAR_MAX columns vary across the different masking
regions?
>
> Thanks,
> John
>
>
> On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > Queue: met_help
> > Subject: SSVAR Output Question
> > Owner: johnhg
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: robert.craig.2 at us.af.mil
Time: Thu Jan 31 12:09:15 2019
I will send a test.
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Thursday, January 31, 2019 1:06 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output Question
Bob,
No, I am not receiving any ARL SAFE emails. Perhaps it's being
filtered out by email filters at NCAR? I'm not sure.
You can definitely try sending it to johnhg at ucar.edu instead.
John
On Thu, Jan 31, 2019 at 11:50 AM robert.craig.2 at us.af.mil via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> John, Matt is out this afternoon but will be in tomorrow. As an
> aside, we did some testing of ARL SAFE where I sent a file to my
home email address.
> My email address should not be any different then met_help as far as
> the system is concerned. I received an email from ARL Safe with the
> link. I clicked the link and initially got an error that I didn't
> have a valid certificate. I clicked cancel and the subsequent
screen
> that came up had more information on the error but had a link at the
> very bottom to return to ARL Safe. When I clicked this then it
should
> the files I had been sent. Are you getting the initial email in
> met_help? Should we be sending it directly to you instead?
>
> Bob
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 12:41 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> <robert.craig.2 at us.af.mil>
> Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
> Question
>
> Matt,
>
> I did some more testing and want to make sure I'm looking at the
data
> in the same way you are.
>
> I grabbed 6 members of GEFS from this site:
>
>
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/
> 00/pgrb2/
>
>
>
>
>
>
>
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00
> z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
>
> I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> temperature to an "observation" of the the first member. Not really
> valid scientifically, but good enough for software testing:
>
>
>
>
>
> */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
>
> And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> (*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
> relevant columns from the *last *SSVAR line for each of these
regions:
>
> *foreach STR (`echo "VERSION FULL NH SH"`)*
>
> * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1
|
> awk '{print $15, $22, $24, $25, $27, $28}'*
> *end*
>
> VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> FULL SSVAR 217 216 223 224
> NH SSVAR 217 216 223 224
> SH SSVAR 78 77 77 78
>
> The maximum variance bin for the FULL globe has endpoints of 223 and
224.
> The maximum must occur in the NH, because it has the same maximum
> variance bin. In the SH, the maximum variance bin is 77 to 78.
This
> output makes sense to me, and I don't see any problems.
>
> Are you interpreting the output the same way... checking to see how
> the VAR_MIN and VAR_MAX columns vary across the different masking
regions?
>
> Thanks,
> John
>
>
> On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > Queue: met_help
> > Subject: SSVAR Output Question
> > Owner: johnhg
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Thu Jan 31 12:25:55 2019
Bob,
I did just receive the test file. That seems to work fine.
John
On Thu, Jan 31, 2019 at 12:09 PM robert.craig.2 at us.af.mil via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> I will send a test.
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 1:06 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
> Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> Question
>
> Bob,
>
> No, I am not receiving any ARL SAFE emails. Perhaps it's being
filtered
> out by email filters at NCAR? I'm not sure.
>
> You can definitely try sending it to johnhg at ucar.edu instead.
>
> John
>
> On Thu, Jan 31, 2019 at 11:50 AM robert.craig.2 at us.af.mil via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
> >
> > John, Matt is out this afternoon but will be in tomorrow. As an
> > aside, we did some testing of ARL SAFE where I sent a file to my
home
> email address.
> > My email address should not be any different then met_help as far
as
> > the system is concerned. I received an email from ARL Safe with
the
> > link. I clicked the link and initially got an error that I didn't
> > have a valid certificate. I clicked cancel and the subsequent
screen
> > that came up had more information on the error but had a link at
the
> > very bottom to return to ARL Safe. When I clicked this then it
should
> > the files I had been sent. Are you getting the initial email in
> > met_help? Should we be sending it directly to you instead?
> >
> > Bob
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT <met_help at ucar.edu>
> > Sent: Thursday, January 31, 2019 12:41 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> > <robert.craig.2 at us.af.mil>
> > Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> > Question
> >
> > Matt,
> >
> > I did some more testing and want to make sure I'm looking at the
data
> > in the same way you are.
> >
> > I grabbed 6 members of GEFS from this site:
> >
> >
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/
> > 00/pgrb2/
> >
> >
> >
> >
> >
> >
> >
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00
> > z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
> >
> > I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> > temperature to an "observation" of the the first member. Not
really
> > valid scientifically, but good enough for software testing:
> >
> >
> >
> >
> >
> > */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> > \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
> >
> > And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> > (*NH*), and the southern hemisphere (*SH*). Below, I've pasted
the
> > relevant columns from the *last *SSVAR line for each of these
regions:
> >
> > *foreach STR (`echo "VERSION FULL NH SH"`)*
> >
> > * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail
-1 |
> > awk '{print $15, $22, $24, $25, $27, $28}'*
> > *end*
> >
> > VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> > FULL SSVAR 217 216 223 224
> > NH SSVAR 217 216 223 224
> > SH SSVAR 78 77 77 78
> >
> > The maximum variance bin for the FULL globe has endpoints of 223
and 224.
> > The maximum must occur in the NH, because it has the same maximum
> > variance bin. In the SH, the maximum variance bin is 77 to 78.
This
> > output makes sense to me, and I don't see any problems.
> >
> > Are you interpreting the output the same way... checking to see
how
> > the VAR_MIN and VAR_MAX columns vary across the different masking
> regions?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > > Queue: met_help
> > > Subject: SSVAR Output Question
> > > Owner: johnhg
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > > >
> > >
> > >
> > > This transaction appears to have no content
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: robert.craig.2 at us.af.mil
Time: Thu Jan 31 12:43:33 2019
Great, we will send there from now on.
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Thursday, January 31, 2019 1:26 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output Question
Bob,
I did just receive the test file. That seems to work fine.
John
On Thu, Jan 31, 2019 at 12:09 PM robert.craig.2 at us.af.mil via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> I will send a test.
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 1:06 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> <robert.craig.2 at us.af.mil>
> Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
> Output Question
>
> Bob,
>
> No, I am not receiving any ARL SAFE emails. Perhaps it's being
> filtered out by email filters at NCAR? I'm not sure.
>
> You can definitely try sending it to johnhg at ucar.edu instead.
>
> John
>
> On Thu, Jan 31, 2019 at 11:50 AM robert.craig.2 at us.af.mil via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
> >
> > John, Matt is out this afternoon but will be in tomorrow. As an
> > aside, we did some testing of ARL SAFE where I sent a file to my
> > home
> email address.
> > My email address should not be any different then met_help as far
as
> > the system is concerned. I received an email from ARL Safe with
the
> > link. I clicked the link and initially got an error that I didn't
> > have a valid certificate. I clicked cancel and the subsequent
> > screen that came up had more information on the error but had a
link
> > at the very bottom to return to ARL Safe. When I clicked this
then
> > it should the files I had been sent. Are you getting the initial
> > email in met_help? Should we be sending it directly to you
instead?
> >
> > Bob
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT <met_help at ucar.edu>
> > Sent: Thursday, January 31, 2019 12:41 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> > <robert.craig.2 at us.af.mil>
> > Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> > Question
> >
> > Matt,
> >
> > I did some more testing and want to make sure I'm looking at the
> > data in the same way you are.
> >
> > I grabbed 6 members of GEFS from this site:
> >
> >
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.2019013
> > 1/
> > 00/pgrb2/
> >
> >
> >
> >
> >
> >
> >
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t
> > 00
> > z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
> >
> > I ran Ensemble-Stat comparing an ensemble of these 6 files for
> > 2-meter temperature to an "observation" of the the first member.
> > Not really valid scientifically, but good enough for software
testing:
> >
> >
> >
> >
> >
> > */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> > \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
> >
> > And I'm computing SSVAR over the *FULL* globe, the Norther
> > Hemisphere (*NH*), and the southern hemisphere (*SH*). Below,
I've
> > pasted the relevant columns from the *last *SSVAR line for each of
these regions:
> >
> > *foreach STR (`echo "VERSION FULL NH SH"`)*
> >
> > * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail
-1
> > | awk '{print $15, $22, $24, $25, $27, $28}'*
> > *end*
> >
> > VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> > FULL SSVAR 217 216 223 224
> > NH SSVAR 217 216 223 224
> > SH SSVAR 78 77 77 78
> >
> > The maximum variance bin for the FULL globe has endpoints of 223
and 224.
> > The maximum must occur in the NH, because it has the same maximum
> > variance bin. In the SH, the maximum variance bin is 77 to 78.
> > This output makes sense to me, and I don't see any problems.
> >
> > Are you interpreting the output the same way... checking to see
how
> > the VAR_MIN and VAR_MAX columns vary across the different masking
> regions?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > > Queue: met_help
> > > Subject: SSVAR Output Question
> > > Owner: johnhg
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > > >
> > >
> > >
> > > This transaction appears to have no content
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Fri Feb 01 07:12:51 2019
Hey John,
Your output looks good; that's what I hoped to get when we ran it
here.
For 240 hour surface temperature, the highest bin is 140-141
(Kelvin^2). Model and obs values are the last two columns in the
output below (normally averages but the count is only 1 in each).
FULL SSVAR 259920 139 138 1 140 141 140.78142
257.6619 252.37999
NH SSVAR 130320 4207 4206 1 5292 5293 5292.55074
229.7057 300.60999
SH SSVAR 130320 3836 3835 1 4524 4525 4524.87896
234.47427 300.38
The huge values for NH and SH don't make sense to me. The numbers
make it seem as if a polar value is being matched to a tropical one.
The input files are 0.5-degree resolution, but ground truth is 0.25-
degree, which gets remapped to 0.5-degree via "obs=fcst". Is it
possible SSVAR sources the 0.25-degree instead? I know that doesn't
make sense but I'm not sure what to think. But the numbers look like
what we see when the two grids are mismatched.
I checked our SSVAR output for irregularly spaced surface observations
and they look fine. But our WWMCA total cloud gridded product also
had the same problem; the highest valued bin in SH was greater than
NH, and both were greater than the highest value in FULL. So it
appears to only be a problem with gridded data.
The masks I'm using are 0.5-degree resolution. I visualized them and
they look fine.
Matt
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Thursday, January 31, 2019 12:41 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
Question
Matt,
I did some more testing and want to make sure I'm looking at the data
in the same way you are.
I grabbed 6 members of GEFS from this site:
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/00/pgrb2/
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-meter
temperature to an "observation" of the the first member. Not really
valid scientifically, but good enough for software testing:
*/usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
\EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
And I'm computing SSVAR over the *FULL* globe, the Norther Hemisphere
(*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
relevant columns from the *last *SSVAR line for each of these regions:
*foreach STR (`echo "VERSION FULL NH SH"`)*
* grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1 |
awk '{print $15, $22, $24, $25, $27, $28}'*
*end*
VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
FULL SSVAR 217 216 223 224
NH SSVAR 217 216 223 224
SH SSVAR 78 77 77 78
The maximum variance bin for the FULL globe has endpoints of 223 and
224.
The maximum must occur in the NH, because it has the same maximum
variance bin. In the SH, the maximum variance bin is 77 to 78. This
output makes sense to me, and I don't see any problems.
Are you interpreting the output the same way... checking to see how
the VAR_MIN and VAR_MAX columns vary across the different masking
regions?
Thanks,
John
On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
met_help at ucar.edu> wrote:
>
> Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by RT_System
> Queue: met_help
> Subject: SSVAR Output Question
> Owner: johnhg
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Fri Feb 01 09:19:16 2019
Matt,
I looked through the posted known issues and bugfixes for met-6.1 and
am
pretty sure I found the smoking gun:
https://dtcenter.org/met/users/support/known_issues/METv6.1/index.php
Look at the issue titled "*Fix ensemble SSVAR output for gridded
observations*" posted about a year ago.
In case you're not able to get to the website, I've copied/pasted it
below. I'm pretty sure that's the culprit.
John
Fix ensemble SSVAR output for gridded observations.
Posted 02/02/2018 *Problem:* Major bug in Ensemble-Stat in the
computation
of SSVAR output using gridded observations. The ensemble mean data was
not
subset correctly for each verification mask causing incorrect variance
and
error computations. Existing SSVAR output which includes this bug
should
not be used. However, SSVAR output computed using point observations
is
correct.
*Solution:* The fix is correctly subsetting the ensemble mean data
when
processing gridded observations. Also, add error checks to the SSVAR
computation to ensure all data arrays are of the same length.
Update: met-6.1/src/tools/core/ensemble_stat/ensemble_stat.cc
<https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/tools/core/ensemble_stat/ensemble_stat.cc>
Update: met-6.1/src/libcode/vx_statistics/pair_data_ensemble.cc
<https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/libcode/vx_statistics/pair_data_ensemble.cc>
On Fri, Feb 1, 2019 at 7:13 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> Hey John,
>
> Your output looks good; that's what I hoped to get when we ran it
here.
>
> For 240 hour surface temperature, the highest bin is 140-141
(Kelvin^2).
> Model and obs values are the last two columns in the output below
(normally
> averages but the count is only 1 in each).
>
> FULL SSVAR 259920 139 138 1 140 141 140.78142
> 257.6619 252.37999
> NH SSVAR 130320 4207 4206 1 5292 5293 5292.55074
> 229.7057 300.60999
> SH SSVAR 130320 3836 3835 1 4524 4525 4524.87896
> 234.47427 300.38
>
> The huge values for NH and SH don't make sense to me. The numbers
make it
> seem as if a polar value is being matched to a tropical one.
>
> The input files are 0.5-degree resolution, but ground truth is
> 0.25-degree, which gets remapped to 0.5-degree via "obs=fcst". Is
it
> possible SSVAR sources the 0.25-degree instead? I know that doesn't
make
> sense but I'm not sure what to think. But the numbers look like
what we
> see when the two grids are mismatched.
>
> I checked our SSVAR output for irregularly spaced surface
observations and
> they look fine. But our WWMCA total cloud gridded product also had
the
> same problem; the highest valued bin in SH was greater than NH, and
both
> were greater than the highest value in FULL. So it appears to only
be a
> problem with gridded data.
>
> The masks I'm using are 0.5-degree resolution. I visualized them
and they
> look fine.
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 12:41 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
> Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
> Question
>
> Matt,
>
> I did some more testing and want to make sure I'm looking at the
data in
> the same way you are.
>
> I grabbed 6 members of GEFS from this site:
>
>
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/00/pgrb2/
>
>
>
>
>
>
>
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
>
> I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> temperature to an "observation" of the the first member. Not really
valid
> scientifically, but good enough for software testing:
>
>
>
>
>
> */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
>
> And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> (*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
> relevant columns from the *last *SSVAR line for each of these
regions:
>
> *foreach STR (`echo "VERSION FULL NH SH"`)*
>
> * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1
| awk
> '{print $15, $22, $24, $25, $27, $28}'*
> *end*
>
> VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> FULL SSVAR 217 216 223 224
> NH SSVAR 217 216 223 224
> SH SSVAR 78 77 77 78
>
> The maximum variance bin for the FULL globe has endpoints of 223 and
224.
> The maximum must occur in the NH, because it has the same maximum
variance
> bin. In the SH, the maximum variance bin is 77 to 78. This output
makes
> sense to me, and I don't see any problems.
>
> Are you interpreting the output the same way... checking to see how
the
> VAR_MIN and VAR_MAX columns vary across the different masking
regions?
>
> Thanks,
> John
>
>
> On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > Queue: met_help
> > Subject: SSVAR Output Question
> > Owner: johnhg
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Fri Feb 01 09:53:54 2019
Thanks John-and I'm pretty sure we never downloaded the patches. Bob
told me we were forbidden to modify 6.1 in any way on our system, so
we may just be stuck with it. At least the full data appear to be
good.
I'm going to bring a DVD with some ensemble files with me to Boulder
next week for the MET tutorial. That way you'll have some of our
sample data should we encounter further issues. Maybe you can
replicate that oddity with the precipitation forecast hour being
written out 6 hours too early.
Matt
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Friday, February 1, 2019 10:19 AM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output Question
Matt,
I looked through the posted known issues and bugfixes for met-6.1 and
am pretty sure I found the smoking gun:
https://dtcenter.org/met/users/support/known_issues/METv6.1/index.php
Look at the issue titled "*Fix ensemble SSVAR output for gridded
observations*" posted about a year ago.
In case you're not able to get to the website, I've copied/pasted it
below. I'm pretty sure that's the culprit.
John
Fix ensemble SSVAR output for gridded observations.
Posted 02/02/2018 *Problem:* Major bug in Ensemble-Stat in the
computation of SSVAR output using gridded observations. The ensemble
mean data was not subset correctly for each verification mask causing
incorrect variance and error computations. Existing SSVAR output which
includes this bug should not be used. However, SSVAR output computed
using point observations is correct.
*Solution:* The fix is correctly subsetting the ensemble mean data
when processing gridded observations. Also, add error checks to the
SSVAR computation to ensure all data arrays are of the same length.
Update: met-6.1/src/tools/core/ensemble_stat/ensemble_stat.cc
<https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/tools/core/ensemble_stat/ensemble_stat.cc>
Update: met-6.1/src/libcode/vx_statistics/pair_data_ensemble.cc
<https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/libcode/vx_statistics/pair_data_ensemble.cc>
On Fri, Feb 1, 2019 at 7:13 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> Hey John,
>
> Your output looks good; that's what I hoped to get when we ran it
here.
>
> For 240 hour surface temperature, the highest bin is 140-141
(Kelvin^2).
> Model and obs values are the last two columns in the output below
> (normally averages but the count is only 1 in each).
>
> FULL SSVAR 259920 139 138 1 140 141 140.78142
> 257.6619 252.37999
> NH SSVAR 130320 4207 4206 1 5292 5293 5292.55074
> 229.7057 300.60999
> SH SSVAR 130320 3836 3835 1 4524 4525 4524.87896
> 234.47427 300.38
>
> The huge values for NH and SH don't make sense to me. The numbers
> make it seem as if a polar value is being matched to a tropical one.
>
> The input files are 0.5-degree resolution, but ground truth is
> 0.25-degree, which gets remapped to 0.5-degree via "obs=fcst". Is
it
> possible SSVAR sources the 0.25-degree instead? I know that doesn't
> make sense but I'm not sure what to think. But the numbers look
like
> what we see when the two grids are mismatched.
>
> I checked our SSVAR output for irregularly spaced surface
observations
> and they look fine. But our WWMCA total cloud gridded product also
> had the same problem; the highest valued bin in SH was greater than
> NH, and both were greater than the highest value in FULL. So it
> appears to only be a problem with gridded data.
>
> The masks I'm using are 0.5-degree resolution. I visualized them
and
> they look fine.
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Thursday, January 31, 2019 12:41 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> <robert.craig.2 at us.af.mil>
> Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output
> Question
>
> Matt,
>
> I did some more testing and want to make sure I'm looking at the
data
> in the same way you are.
>
> I grabbed 6 members of GEFS from this site:
>
>
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/
> 00/pgrb2/
>
>
>
>
>
>
>
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00
> z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
>
> I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> temperature to an "observation" of the the first member. Not really
> valid scientifically, but good enough for software testing:
>
>
>
>
>
> */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
>
> And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> (*NH*), and the southern hemisphere (*SH*). Below, I've pasted the
> relevant columns from the *last *SSVAR line for each of these
regions:
>
> *foreach STR (`echo "VERSION FULL NH SH"`)*
>
> * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail -1
|
> awk '{print $15, $22, $24, $25, $27, $28}'*
> *end*
>
> VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> FULL SSVAR 217 216 223 224
> NH SSVAR 217 216 223 224
> SH SSVAR 78 77 77 78
>
> The maximum variance bin for the FULL globe has endpoints of 223 and
224.
> The maximum must occur in the NH, because it has the same maximum
> variance bin. In the SH, the maximum variance bin is 77 to 78.
This
> output makes sense to me, and I don't see any problems.
>
> Are you interpreting the output the same way... checking to see how
> the VAR_MIN and VAR_MAX columns vary across the different masking
regions?
>
> Thanks,
> John
>
>
> On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > Queue: met_help
> > Subject: SSVAR Output Question
> > Owner: johnhg
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
Subject: SSVAR Output Question
From: John Halley Gotway
Time: Fri Feb 01 13:19:51 2019
Matt,
Sounds good, and I look forward to seeing you next week!
We had a telecon with the AF earlier this week (including Bob) and got
the
go ahead to install the first beta version of met-8.1 on dev9. That
includes many of the Fortify fixes, but we still do have more issues
to
address. That should give you a better version to try out.
Thanks,
John
On Fri, Feb 1, 2019 at 9:54 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> Thanks John-and I'm pretty sure we never downloaded the patches.
Bob told
> me we were forbidden to modify 6.1 in any way on our system, so we
may just
> be stuck with it. At least the full data appear to be good.
>
> I'm going to bring a DVD with some ensemble files with me to Boulder
next
> week for the MET tutorial. That way you'll have some of our sample
data
> should we encounter further issues. Maybe you can replicate that
oddity
> with the precipitation forecast hour being written out 6 hours too
early.
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Friday, February 1, 2019 10:19 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
> Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> Question
>
> Matt,
>
> I looked through the posted known issues and bugfixes for met-6.1
and am
> pretty sure I found the smoking gun:
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/index.php
> Look at the issue titled "*Fix ensemble SSVAR output for gridded
> observations*" posted about a year ago.
>
> In case you're not able to get to the website, I've copied/pasted it
> below. I'm pretty sure that's the culprit.
>
> John
>
> Fix ensemble SSVAR output for gridded observations.
> Posted 02/02/2018 *Problem:* Major bug in Ensemble-Stat in the
computation
> of SSVAR output using gridded observations. The ensemble mean data
was not
> subset correctly for each verification mask causing incorrect
variance and
> error computations. Existing SSVAR output which includes this bug
should
> not be used. However, SSVAR output computed using point observations
is
> correct.
> *Solution:* The fix is correctly subsetting the ensemble mean data
when
> processing gridded observations. Also, add error checks to the SSVAR
> computation to ensure all data arrays are of the same length.
> Update: met-6.1/src/tools/core/ensemble_stat/ensemble_stat.cc
> <
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/tools/core/ensemble_stat/ensemble_stat.cc
> >
> Update: met-6.1/src/libcode/vx_statistics/pair_data_ensemble.cc
> <
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/src/libcode/vx_statistics/pair_data_ensemble.cc
> >
>
> On Fri, Feb 1, 2019 at 7:13 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
> via RT <met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
> >
> > Hey John,
> >
> > Your output looks good; that's what I hoped to get when we ran it
here.
> >
> > For 240 hour surface temperature, the highest bin is 140-141
(Kelvin^2).
> > Model and obs values are the last two columns in the output below
> > (normally averages but the count is only 1 in each).
> >
> > FULL SSVAR 259920 139 138 1 140 141
140.78142
> > 257.6619 252.37999
> > NH SSVAR 130320 4207 4206 1 5292 5293
5292.55074
> > 229.7057 300.60999
> > SH SSVAR 130320 3836 3835 1 4524 4525
4524.87896
> > 234.47427 300.38
> >
> > The huge values for NH and SH don't make sense to me. The numbers
> > make it seem as if a polar value is being matched to a tropical
one.
> >
> > The input files are 0.5-degree resolution, but ground truth is
> > 0.25-degree, which gets remapped to 0.5-degree via "obs=fcst". Is
it
> > possible SSVAR sources the 0.25-degree instead? I know that
doesn't
> > make sense but I'm not sure what to think. But the numbers look
like
> > what we see when the two grids are mismatched.
> >
> > I checked our SSVAR output for irregularly spaced surface
observations
> > and they look fine. But our WWMCA total cloud gridded product
also
> > had the same problem; the highest valued bin in SH was greater
than
> > NH, and both were greater than the highest value in FULL. So it
> > appears to only be a problem with gridded data.
> >
> > The masks I'm using are 0.5-degree resolution. I visualized them
and
> > they look fine.
> >
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT <met_help at ucar.edu>
> > Sent: Thursday, January 31, 2019 12:41 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> > <robert.craig.2 at us.af.mil>
> > Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> > Question
> >
> > Matt,
> >
> > I did some more testing and want to make sure I'm looking at the
data
> > in the same way you are.
> >
> > I grabbed 6 members of GEFS from this site:
> >
> >
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.20190131/
> > 00/pgrb2/
> >
> >
> >
> >
> >
> >
> >
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t00
> > z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
> >
> > I ran Ensemble-Stat comparing an ensemble of these 6 files for 2-
meter
> > temperature to an "observation" of the the first member. Not
really
> > valid scientifically, but good enough for software testing:
> >
> >
> >
> >
> >
> > */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> > \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
> >
> > And I'm computing SSVAR over the *FULL* globe, the Norther
Hemisphere
> > (*NH*), and the southern hemisphere (*SH*). Below, I've pasted
the
> > relevant columns from the *last *SSVAR line for each of these
regions:
> >
> > *foreach STR (`echo "VERSION FULL NH SH"`)*
> >
> > * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail
-1 |
> > awk '{print $15, $22, $24, $25, $27, $28}'*
> > *end*
> >
> > VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> > FULL SSVAR 217 216 223 224
> > NH SSVAR 217 216 223 224
> > SH SSVAR 78 77 77 78
> >
> > The maximum variance bin for the FULL globe has endpoints of 223
and 224.
> > The maximum must occur in the NH, because it has the same maximum
> > variance bin. In the SH, the maximum variance bin is 77 to 78.
This
> > output makes sense to me, and I don't see any problems.
> >
> > Are you interpreting the output the same way... checking to see
how
> > the VAR_MIN and VAR_MAX columns vary across the different masking
> regions?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > > Queue: met_help
> > > Subject: SSVAR Output Question
> > > Owner: johnhg
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > > >
> > >
> > >
> > > This transaction appears to have no content
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR Output Question
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Fri Feb 01 13:30:53 2019
Looks like decent weather out there, for the weekend at least. I'm
driving out tomorrow so I'll have all day Sunday to enjoy the great
outdoors before the tutorial starts.
Matt
-----Original Message-----
From: John Halley Gotway via RT <met_help at ucar.edu>
Sent: Friday, February 1, 2019 2:20 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
<robert.craig.2 at us.af.mil>
Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output Question
Matt,
Sounds good, and I look forward to seeing you next week!
We had a telecon with the AF earlier this week (including Bob) and got
the go ahead to install the first beta version of met-8.1 on dev9.
That includes many of the Fortify fixes, but we still do have more
issues to address. That should give you a better version to try out.
Thanks,
John
On Fri, Feb 1, 2019 at 9:54 AM SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
>
> Thanks John-and I'm pretty sure we never downloaded the patches.
Bob
> told me we were forbidden to modify 6.1 in any way on our system, so
> we may just be stuck with it. At least the full data appear to be
good.
>
> I'm going to bring a DVD with some ensemble files with me to Boulder
> next week for the MET tutorial. That way you'll have some of our
> sample data should we encounter further issues. Maybe you can
> replicate that oddity with the precipitation forecast hour being
written out 6 hours too early.
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT <met_help at ucar.edu>
> Sent: Friday, February 1, 2019 10:19 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> <robert.craig.2 at us.af.mil>
> Subject: Re: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
> Output Question
>
> Matt,
>
> I looked through the posted known issues and bugfixes for met-6.1
and
> am pretty sure I found the smoking gun:
>
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/index.php
> Look at the issue titled "*Fix ensemble SSVAR output for gridded
> observations*" posted about a year ago.
>
> In case you're not able to get to the website, I've copied/pasted it
> below. I'm pretty sure that's the culprit.
>
> John
>
> Fix ensemble SSVAR output for gridded observations.
> Posted 02/02/2018 *Problem:* Major bug in Ensemble-Stat in the
> computation of SSVAR output using gridded observations. The ensemble
> mean data was not subset correctly for each verification mask
causing
> incorrect variance and error computations. Existing SSVAR output
which
> includes this bug should not be used. However, SSVAR output computed
> using point observations is correct.
> *Solution:* The fix is correctly subsetting the ensemble mean data
> when processing gridded observations. Also, add error checks to the
> SSVAR computation to ensure all data arrays are of the same length.
> Update: met-6.1/src/tools/core/ensemble_stat/ensemble_stat.cc
> <
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/sr
> c/tools/core/ensemble_stat/ensemble_stat.cc
> >
> Update: met-6.1/src/libcode/vx_statistics/pair_data_ensemble.cc
> <
>
https://dtcenter.org/met/users/support/known_issues/METv6.1/patches/sr
> c/libcode/vx_statistics/pair_data_ensemble.cc
> >
>
> On Fri, Feb 1, 2019 at 7:13 AM SITTEL, MATTHEW C CTR USAF AFWA 16
> WS/WXN via RT <met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718 >
> >
> > Hey John,
> >
> > Your output looks good; that's what I hoped to get when we ran it
here.
> >
> > For 240 hour surface temperature, the highest bin is 140-141
(Kelvin^2).
> > Model and obs values are the last two columns in the output below
> > (normally averages but the count is only 1 in each).
> >
> > FULL SSVAR 259920 139 138 1 140 141
140.78142
> > 257.6619 252.37999
> > NH SSVAR 130320 4207 4206 1 5292 5293
5292.55074
> > 229.7057 300.60999
> > SH SSVAR 130320 3836 3835 1 4524 4525
4524.87896
> > 234.47427 300.38
> >
> > The huge values for NH and SH don't make sense to me. The numbers
> > make it seem as if a polar value is being matched to a tropical
one.
> >
> > The input files are 0.5-degree resolution, but ground truth is
> > 0.25-degree, which gets remapped to 0.5-degree via "obs=fcst". Is
> > it possible SSVAR sources the 0.25-degree instead? I know that
> > doesn't make sense but I'm not sure what to think. But the
numbers
> > look like what we see when the two grids are mismatched.
> >
> > I checked our SSVAR output for irregularly spaced surface
> > observations and they look fine. But our WWMCA total cloud
gridded
> > product also had the same problem; the highest valued bin in SH
was
> > greater than NH, and both were greater than the highest value in
> > FULL. So it appears to only be a problem with gridded data.
> >
> > The masks I'm using are 0.5-degree resolution. I visualized them
> > and they look fine.
> >
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT <met_help at ucar.edu>
> > Sent: Thursday, January 31, 2019 12:41 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Cc: CRAIG, ROBERT J GS-12 USAF ACC 16 WS/WXN
> > <robert.craig.2 at us.af.mil>
> > Subject: [Non-DoD Source] Re: [rt.rap.ucar.edu #88718] SSVAR
Output
> > Question
> >
> > Matt,
> >
> > I did some more testing and want to make sure I'm looking at the
> > data in the same way you are.
> >
> > I grabbed 6 members of GEFS from this site:
> >
> >
http://nomads.ncep.noaa.gov/pub/data/nccf/com/gens/prod/gefs.2019013
> > 1/
> > 00/pgrb2/
> >
> >
> >
> >
> >
> >
> >
*gep01.t00z.pgrb2f240gep02.t00z.pgrb2f240gep03.t00z.pgrb2f240gep04.t
> > 00
> > z.pgrb2f240gep05.t00z.pgrb2f240gep06.t00z.pgrb2f240*
> >
> > I ran Ensemble-Stat comparing an ensemble of these 6 files for
> > 2-meter temperature to an "observation" of the the first member.
> > Not really valid scientifically, but good enough for software
testing:
> >
> >
> >
> >
> >
> > */usr/local/met-6.1/bin/ensemble_stat \6 gep0*.t00z.pgrb2f240
> > \EnsembleStatConfig \-grid_obs gep01.t00z.pgrb2f240 \-outdir out*
> >
> > And I'm computing SSVAR over the *FULL* globe, the Norther
> > Hemisphere (*NH*), and the southern hemisphere (*SH*). Below,
I've
> > pasted the relevant columns from the *last *SSVAR line for each of
these regions:
> >
> > *foreach STR (`echo "VERSION FULL NH SH"`)*
> >
> > * grep $STR out/ensemble_stat_20190210_000000V_ssvar.txt | tail
-1
> > | awk '{print $15, $22, $24, $25, $27, $28}'*
> > *end*
> >
> > VX_MASK LINE_TYPE N_BIN BIN_i VAR_MIN VAR_MAX
> > FULL SSVAR 217 216 223 224
> > NH SSVAR 217 216 223 224
> > SH SSVAR 78 77 77 78
> >
> > The maximum variance bin for the FULL globe has endpoints of 223
and 224.
> > The maximum must occur in the NH, because it has the same maximum
> > variance bin. In the SH, the maximum variance bin is 77 to 78.
> > This output makes sense to me, and I don't see any problems.
> >
> > Are you interpreting the output the same way... checking to see
how
> > the VAR_MIN and VAR_MAX columns vary across the different masking
> regions?
> >
> > Thanks,
> > John
> >
> >
> > On Thu, Jan 31, 2019 at 11:01 AM The RT System itself via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Thu Jan 31 11:00:10 2019: Request 88718 was acted upon.
> > > Transaction: Given to johnhg (John Halley Gotway) by RT_System
> > > Queue: met_help
> > > Subject: SSVAR Output Question
> > > Owner: johnhg
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=88718
> > > >
> > >
> > >
> > > This transaction appears to have no content
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list