[Met_help] [rt.rap.ucar.edu #76735] History for Confusion over MODE .obj Output
John Halley Gotway via RT
met_help at ucar.edu
Fri Jun 17 09:44:34 MDT 2016
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I'm trying to figure out if I have a problem with the way I have configured MODE to run.
I am attempting to build cloud objects (based on a threshold of cloud cover being 95% or greater) from DCF cloud model data and WWMCA ground truth analyses.
In the example I just ran I have entries in an output .obj file, one line for each of the 30 forecast objects, then a line for each of 26 observation objects, and lines for each of the 30x26 forecast-observation pairs.
Below are a few lines from the output file.
VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD OBS_VALID OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY INTENSITY_10 INTENSITY_25 INTENSITY_50 INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM CENTROID_DIST BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF INTERSECTION_OVER_AREA COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F001 CF000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F002 CF000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F003 CF000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC O001 CO000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC O002 CO000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC O003 CO000 0 0 -20.837 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NA NA NA NA NA NA NA NA NA NA NA NA
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F001_O001 CF000_CO000 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 0 0 0 0 0 0 0 0 0 0 0 0
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F001_O002 CF000_CO000 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 0 0 0 0 0 0 0 0 0 0 0 0
V5.1 DCF 360000 20160402_120000 000000 000000 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC L0 Cloud_Pct SFC F001_O003 CF000_CO000 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 0 0 0 0 0 0 0 0 0 0 0 0
What I can't figure out is how MODE apparently diagnosed 30 forecast objects and 26 observation objects, but has nothing but zeroes and missing values.
A couple of parts that might be of concern, or help in diagnosing:
1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is indicative of the problem.
2. The centroid lat/lon of each object is always the same. This is a northern hemisphere product and I believe (-20.837,55) is a corner point for the WWMCA data. Note that the WWMCA observation data are created by WWMCA_REGRID.
// SIGNED //
Matthew C. Sittel
University Corporation for Atmospheric Research
16 WS/WXN, 557 WW, Offutt AFB, NE
matthew.sittel.ctr at us.af.mil
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Mon Jun 13 10:18:03 2016
Matt,
Yes, that certainly doesn't look like very meaningful output from
MODE!
Regarding the OBS_ACCUM being set to "-02-46-39", if you do the math
-2
hours, 46 minutes, and 39 seconds equals -9999, which curiously, is
the
value we use for missing data. I strongly suspect that we're missing
a
check for bad data somewhere. When the accumulation interval is bad
data
(-9999), we should either write out "000000" or "NA". Using "00000"
would
likely avoid parsing headaches down the line. But no, I don't think
this
has anything to do with the bad object output you're getting.
Are you able to send me sample files for your MODE run (fcst, obs, and
config file)? I'll run it here, reproduce the behavior you're seeing,
and
then try to figure it out. Could you post it to our anonymous ftp
site?
Being able to replicate the "-02-46-39" will make it easy for me to
fix
that one.
Thanks,
John
On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
via RT <met_help at ucar.edu> wrote:
>
> Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> Queue: met_help
> Subject: Confusion over MODE .obj Output
> Owner: Nobody
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735 >
>
>
> Hi,
>
> I'm trying to figure out if I have a problem with the way I have
> configured MODE to run.
>
> I am attempting to build cloud objects (based on a threshold of
cloud
> cover being 95% or greater) from DCF cloud model data and WWMCA
ground
> truth analyses.
>
> In the example I just ran I have entries in an output .obj file, one
line
> for each of the 30 forecast objects, then a line for each of 26
observation
> objects, and lines for each of the 30x26 forecast-observation pairs.
>
> Below are a few lines from the output file.
>
> VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
OBS_VAR
> OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y CENTROID_LAT
> CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER AREA_THRESH
CURVATURE
> CURVATURE_X CURVATURE_Y COMPLEXITY INTENSITY_10 INTENSITY_25
INTENSITY_50
> INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM CENTROID_DIST
> BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
INTERSECTION_AREA
> UNION_AREA SYMMETRIC_DIFF INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> PERCENTILE_INTENSITY_RATIO INTEREST
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F002 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F003 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O001 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O002 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O003 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
>
> What I can't figure out is how MODE apparently diagnosed 30 forecast
> objects and 26 observation objects, but has nothing but zeroes and
missing
> values.
>
> A couple of parts that might be of concern, or help in diagnosing:
>
> 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
indicative of
> the problem.
> 2. The centroid lat/lon of each object is always the same. This is
a
> northern hemisphere product and I believe (-20.837,55) is a corner
point
> for the WWMCA data. Note that the WWMCA observation data are
created by
> WWMCA_REGRID.
>
> // SIGNED //
> Matthew C. Sittel
> University Corporation for Atmospheric Research
> 16 WS/WXN, 557 WW, Offutt AFB, NE
> matthew.sittel.ctr at us.af.mil
>
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Mon Jun 13 10:31:02 2016
I just posted the files in 'sittel_data'. This is using the recently
recompiled v5.1 executables.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, June 13, 2016 11:18 AM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Yes, that certainly doesn't look like very meaningful output from
MODE!
Regarding the OBS_ACCUM being set to "-02-46-39", if you do the math
-2 hours, 46 minutes, and 39 seconds equals -9999, which curiously, is
the value we use for missing data. I strongly suspect that we're
missing a check for bad data somewhere. When the accumulation
interval is bad data (-9999), we should either write out "000000" or
"NA". Using "00000" would likely avoid parsing headaches down the
line. But no, I don't think this has anything to do with the bad
object output you're getting.
Are you able to send me sample files for your MODE run (fcst, obs, and
config file)? I'll run it here, reproduce the behavior you're seeing,
and then try to figure it out. Could you post it to our anonymous ftp
site?
Being able to replicate the "-02-46-39" will make it easy for me to
fix that one.
Thanks,
John
On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN via RT <met_help at ucar.edu> wrote:
>
> Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> Queue: met_help
> Subject: Confusion over MODE .obj Output
> Owner: Nobody
> Requestors: matthew.sittel.ctr at us.af.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> >
>
>
> Hi,
>
> I'm trying to figure out if I have a problem with the way I have
> configured MODE to run.
>
> I am attempting to build cloud objects (based on a threshold of
cloud
> cover being 95% or greater) from DCF cloud model data and WWMCA
ground
> truth analyses.
>
> In the example I just ran I have entries in an output .obj file, one
> line for each of the 30 forecast objects, then a line for each of 26
> observation objects, and lines for each of the 30x26 forecast-
observation pairs.
>
> Below are a few lines from the output file.
>
> VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
OBS_VAR
> OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y CENTROID_LAT
> CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER AREA_THRESH
> CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY INTENSITY_10
INTENSITY_25 INTENSITY_50
> INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM CENTROID_DIST
> BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
INTERSECTION_AREA
> UNION_AREA SYMMETRIC_DIFF INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> PERCENTILE_INTENSITY_RATIO INTEREST
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F002 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F003 CF000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O001 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O002 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC O003 CO000 0 0
> -20.837 55 0 0 0 0 0
0
> 0 0 0 0 0 0
> 0 0 0 0 0
NA
> NA NA NA NA
NA
> NA NA NA NA
> NA NA
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
> V5.1 DCF 360000 20160402_120000 000000 000000
> 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
NA
> NA NA NA NA NA NA NA
> NA NA NA NA NA NA
> NA NA NA NA NA
0
> 0 0 0 0 0
> 0 0 0 0
> 0 0
>
> What I can't figure out is how MODE apparently diagnosed 30 forecast
> objects and 26 observation objects, but has nothing but zeroes and
> missing values.
>
> A couple of parts that might be of concern, or help in diagnosing:
>
> 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
indicative
> of the problem.
> 2. The centroid lat/lon of each object is always the same. This is
a
> northern hemisphere product and I believe (-20.837,55) is a corner
> point for the WWMCA data. Note that the WWMCA observation data are
> created by WWMCA_REGRID.
>
> // SIGNED //
> Matthew C. Sittel
> University Corporation for Atmospheric Research
> 16 WS/WXN, 557 WW, Offutt AFB, NE
> matthew.sittel.ctr at us.af.mil
>
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Mon Jun 13 14:50:26 2016
Matt,
OK, here's what I've found...
(1) wwmca_regrid version 5.1 writes the accumulation interval global
attribute like this:
Cloud_Pct:accum_time = "1 hour" ;
The current development version (i.e. for the 5.2 release) writes it
like
this:
Cloud_Pct:accum_time = "010000" ;
Cloud_Pct:accum_time_sec = 3600 ;
MET actually doesn't even parse the "accum_time" string. Instead, its
looking for "accum_time_sec". Since that is missing, the accumulation
interval is set to it's default value of bad data (i.e. a value of
-9999).
We are failing to check for bad data and -9999 is interpreted as a
number
of second and converted to that weird string "-02-46-39".
Version 5.2 of wwmca_regrid will store the accumulation interval in
the
expected way. So it won't have this bad data issue.
However, this is the second time this weird string has popped up.
I'll add
some logic to check for this and write "000000" instead of "-02-46-
39".
(2) I ran plot_data_plane on the data files you sent and have attached
the
resulting images in PNG format. The GRIB1 forecast looks fine but the
WWMCA data does not:
/d1/johnhg/MET/MET_development/
svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
fcsts_t005_2016040100_036.GR1 \
fcsts_t005_2016040100_036_TCDC.ps \
'name="TCDC"; level="L0";'
/d1/johnhg/MET/MET_development/
svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
'name="Cloud_Pct"; level="(*,*)";'
Notice how weird the WWMCA map data looks. I think we should step
back and
work on the wwmca_regrid output. Can you tell me what commands you
used to
run that one?
FYI, when I ran MODE on this data, I didn't see all the 0's you were
seeing. I got reasonable looking output. But let's straighten out
wwmca_regrid before moving on to that.
Thanks,
John
On Mon, Jun 13, 2016 at 10:31 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=76735 >
>
> I just posted the files in 'sittel_data'. This is using the
recently
> recompiled v5.1 executables.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, June 13, 2016 11:18 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Yes, that certainly doesn't look like very meaningful output from
MODE!
>
> Regarding the OBS_ACCUM being set to "-02-46-39", if you do the math
-2
> hours, 46 minutes, and 39 seconds equals -9999, which curiously, is
the
> value we use for missing data. I strongly suspect that we're
missing a
> check for bad data somewhere. When the accumulation interval is bad
data
> (-9999), we should either write out "000000" or "NA". Using "00000"
would
> likely avoid parsing headaches down the line. But no, I don't think
this
> has anything to do with the bad object output you're getting.
>
> Are you able to send me sample files for your MODE run (fcst, obs,
and
> config file)? I'll run it here, reproduce the behavior you're
seeing, and
> then try to figure it out. Could you post it to our anonymous ftp
site?
>
> Being able to replicate the "-02-46-39" will make it easy for me to
fix
> that one.
>
> Thanks,
> John
>
>
> On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA 16
WS/WXN
> via RT <met_help at ucar.edu> wrote:
>
> >
> > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > Queue: met_help
> > Subject: Confusion over MODE .obj Output
> > Owner: Nobody
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > >
> >
> >
> > Hi,
> >
> > I'm trying to figure out if I have a problem with the way I have
> > configured MODE to run.
> >
> > I am attempting to build cloud objects (based on a threshold of
cloud
> > cover being 95% or greater) from DCF cloud model data and WWMCA
ground
> > truth analyses.
> >
> > In the example I just ran I have entries in an output .obj file,
one
> > line for each of the 30 forecast objects, then a line for each of
26
> > observation objects, and lines for each of the 30x26
> forecast-observation pairs.
> >
> > Below are a few lines from the output file.
> >
> > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
OBS_VAR
> > OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y CENTROID_LAT
> > CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER AREA_THRESH
> > CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY INTENSITY_10
INTENSITY_25
> INTENSITY_50
> > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
INTERSECTION_AREA
> > UNION_AREA SYMMETRIC_DIFF INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> > PERCENTILE_INTENSITY_RATIO INTEREST
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F002 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F003 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O001 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O002 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O003 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> >
> > What I can't figure out is how MODE apparently diagnosed 30
forecast
> > objects and 26 observation objects, but has nothing but zeroes and
> > missing values.
> >
> > A couple of parts that might be of concern, or help in diagnosing:
> >
> > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
indicative
> > of the problem.
> > 2. The centroid lat/lon of each object is always the same. This
is a
> > northern hemisphere product and I believe (-20.837,55) is a corner
> > point for the WWMCA data. Note that the WWMCA observation data
are
> > created by WWMCA_REGRID.
> >
> > // SIGNED //
> > Matthew C. Sittel
> > University Corporation for Atmospheric Research
> > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > matthew.sittel.ctr at us.af.mil
> >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Tue Jun 14 06:42:15 2016
Hi John,
Wow, that WWMCA is way off. Here's how I call it:
${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file} -nh
${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
I pushed the NH and SH WWMCA files to the FTP site for you just now
(should have thought to do that yesterday).
The config file contents:
regrid = {
to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813 6367.47
0 N";
vld_thresh = 0.5;
method = NEAREST;
width = 1;
}
////////////////////////////////////////////////////////////////////////////////
//
// NetCDF output information
//
variable_name = "Cloud_Pct";
units = "percent";
long_name = "cloud cover percent";
level = "SFC";
////////////////////////////////////////////////////////////////////////////////
//
// Maximum pixel age in minutes
//
max_minutes = 1440;
I'm guessing I messed up the "to_grid"? I was trying to get it to
match the model data of course.
Thanks,
Matt
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, June 13, 2016 3:50 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
OK, here's what I've found...
(1) wwmca_regrid version 5.1 writes the accumulation interval global
attribute like this:
Cloud_Pct:accum_time = "1 hour" ;
The current development version (i.e. for the 5.2 release) writes it
like
this:
Cloud_Pct:accum_time = "010000" ;
Cloud_Pct:accum_time_sec = 3600 ;
MET actually doesn't even parse the "accum_time" string. Instead, its
looking for "accum_time_sec". Since that is missing, the accumulation
interval is set to it's default value of bad data (i.e. a value of
-9999).
We are failing to check for bad data and -9999 is interpreted as a
number of second and converted to that weird string "-02-46-39".
Version 5.2 of wwmca_regrid will store the accumulation interval in
the expected way. So it won't have this bad data issue.
However, this is the second time this weird string has popped up.
I'll add some logic to check for this and write "000000" instead of "-
02-46-39".
(2) I ran plot_data_plane on the data files you sent and have attached
the resulting images in PNG format. The GRIB1 forecast looks fine but
the WWMCA data does not:
/d1/johnhg/MET/MET_development/
svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
fcsts_t005_2016040100_036.GR1 \
fcsts_t005_2016040100_036_TCDC.ps \
'name="TCDC"; level="L0";'
/d1/johnhg/MET/MET_development/
svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \ 'name="Cloud_Pct";
level="(*,*)";'
Notice how weird the WWMCA map data looks. I think we should step
back and work on the wwmca_regrid output. Can you tell me what
commands you used to run that one?
FYI, when I ran MODE on this data, I didn't see all the 0's you were
seeing. I got reasonable looking output. But let's straighten out
wwmca_regrid before moving on to that.
Thanks,
John
On Mon, Jun 13, 2016 at 10:31 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=76735 >
>
> I just posted the files in 'sittel_data'. This is using the
recently
> recompiled v5.1 executables.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, June 13, 2016 11:18 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Yes, that certainly doesn't look like very meaningful output from
MODE!
>
> Regarding the OBS_ACCUM being set to "-02-46-39", if you do the math
> -2 hours, 46 minutes, and 39 seconds equals -9999, which curiously,
is
> the value we use for missing data. I strongly suspect that we're
> missing a check for bad data somewhere. When the accumulation
> interval is bad data (-9999), we should either write out "000000" or
> "NA". Using "00000" would likely avoid parsing headaches down the
> line. But no, I don't think this has anything to do with the bad
object output you're getting.
>
> Are you able to send me sample files for your MODE run (fcst, obs,
and
> config file)? I'll run it here, reproduce the behavior you're
seeing,
> and then try to figure it out. Could you post it to our anonymous
ftp site?
>
> Being able to replicate the "-02-46-39" will make it easy for me to
> fix that one.
>
> Thanks,
> John
>
>
> On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA 16
> WS/WXN via RT <met_help at ucar.edu> wrote:
>
> >
> > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > Queue: met_help
> > Subject: Confusion over MODE .obj Output
> > Owner: Nobody
> > Requestors: matthew.sittel.ctr at us.af.mil
> > Status: new
> > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > >
> >
> >
> > Hi,
> >
> > I'm trying to figure out if I have a problem with the way I have
> > configured MODE to run.
> >
> > I am attempting to build cloud objects (based on a threshold of
> > cloud cover being 95% or greater) from DCF cloud model data and
> > WWMCA ground truth analyses.
> >
> > In the example I just ran I have entries in an output .obj file,
one
> > line for each of the 30 forecast objects, then a line for each of
26
> > observation objects, and lines for each of the 30x26
> forecast-observation pairs.
> >
> > Below are a few lines from the output file.
> >
> > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER
> > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > INTENSITY_10 INTENSITY_25
> INTENSITY_50
> > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF INTERSECTION_OVER_AREA
> > COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F002 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F003 CF000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O001 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O002 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC O003 CO000 0 0
> > -20.837 55 0 0 0 0 0
0
> > 0 0 0 0 0
0
> > 0 0 0 0 0
> NA
> > NA NA NA NA
NA
> > NA NA NA NA
> > NA NA
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> > V5.1 DCF 360000 20160402_120000 000000 000000
> > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0 TCDC
L0
> > Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
NA
> > NA NA NA NA NA NA NA
> > NA NA NA NA NA NA
> > NA NA NA NA NA
0
> > 0 0 0 0
0
> > 0 0 0 0
> > 0 0
> >
> > What I can't figure out is how MODE apparently diagnosed 30
forecast
> > objects and 26 observation objects, but has nothing but zeroes and
> > missing values.
> >
> > A couple of parts that might be of concern, or help in diagnosing:
> >
> > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > indicative of the problem.
> > 2. The centroid lat/lon of each object is always the same. This
is
> > a northern hemisphere product and I believe (-20.837,55) is a
corner
> > point for the WWMCA data. Note that the WWMCA observation data
are
> > created by WWMCA_REGRID.
> >
> > // SIGNED //
> > Matthew C. Sittel
> > University Corporation for Atmospheric Research
> > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > matthew.sittel.ctr at us.af.mil
> >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Tue Jun 14 10:26:00 2016
Matt,
Thanks for sending the WWMCA-Regrid config file info. When I used
your
settings, I was able to replicate your "bad" result. The WWMCA-North
and
WWMCA-South grids are actually predefined in the code and named
"wwma_north" and "wwmca_south". So I updated the "to_grid" in your
config
file to read:
to_grid = "wwmca_north";
Then I plotted/attached the result. I also attached the plot of the
forecast data for reference. Notice that the forecast grid is upside-
down
and flipped relative to the WWMCA grid. So you will need to use the
"regrid" option when running mode to compare this data. If you pass
the
"fcsts_t005..." file as the forecast and the WWMCA data as the
observation,
my suggestion would be to regrid to the OBS field. That way the
output
will be on the conventional WWMCA North grid.
Please give that a shot and take a close look at both the ascii output
from
MODE and the PostScript output.
Hope that helps.
John
On Tue, Jun 14, 2016 at 6:42 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=76735 >
>
> Hi John,
>
> Wow, that WWMCA is way off. Here's how I call it:
>
> ${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file}
-nh
> ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
>
> I pushed the NH and SH WWMCA files to the FTP site for you just now
> (should have thought to do that yesterday).
>
> The config file contents:
>
> regrid = {
> to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47 0
> N";
> vld_thresh = 0.5;
> method = NEAREST;
> width = 1;
> }
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // NetCDF output information
> //
> variable_name = "Cloud_Pct";
> units = "percent";
> long_name = "cloud cover percent";
> level = "SFC";
>
>
>
////////////////////////////////////////////////////////////////////////////////
>
> //
> // Maximum pixel age in minutes
> //
> max_minutes = 1440;
>
> I'm guessing I messed up the "to_grid"? I was trying to get it to
match
> the model data of course.
>
> Thanks,
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, June 13, 2016 3:50 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> OK, here's what I've found...
>
> (1) wwmca_regrid version 5.1 writes the accumulation interval global
> attribute like this:
> Cloud_Pct:accum_time = "1 hour" ;
>
> The current development version (i.e. for the 5.2 release) writes it
like
> this:
> Cloud_Pct:accum_time = "010000" ;
> Cloud_Pct:accum_time_sec = 3600 ;
>
> MET actually doesn't even parse the "accum_time" string. Instead,
its
> looking for "accum_time_sec". Since that is missing, the
accumulation
> interval is set to it's default value of bad data (i.e. a value of
-9999).
> We are failing to check for bad data and -9999 is interpreted as a
number
> of second and converted to that weird string "-02-46-39".
>
> Version 5.2 of wwmca_regrid will store the accumulation interval in
the
> expected way. So it won't have this bad data issue.
>
> However, this is the second time this weird string has popped up.
I'll
> add some logic to check for this and write "000000" instead of "-02-
46-39".
>
> (2) I ran plot_data_plane on the data files you sent and have
attached the
> resulting images in PNG format. The GRIB1 forecast looks fine but
the
> WWMCA data does not:
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> fcsts_t005_2016040100_036.GR1 \
> fcsts_t005_2016040100_036_TCDC.ps \
> 'name="TCDC"; level="L0";'
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \ 'name="Cloud_Pct";
> level="(*,*)";'
>
> Notice how weird the WWMCA map data looks. I think we should step
back
> and work on the wwmca_regrid output. Can you tell me what commands
you
> used to run that one?
>
> FYI, when I ran MODE on this data, I didn't see all the 0's you were
> seeing. I got reasonable looking output. But let's straighten out
> wwmca_regrid before moving on to that.
>
> Thanks,
> John
>
>
>
>
> On Mon, Jun 13, 2016 at 10:31 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=76735 >
> >
> > I just posted the files in 'sittel_data'. This is using the
recently
> > recompiled v5.1 executables.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, June 13, 2016 11:18 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
> >
> > Matt,
> >
> > Yes, that certainly doesn't look like very meaningful output from
MODE!
> >
> > Regarding the OBS_ACCUM being set to "-02-46-39", if you do the
math
> > -2 hours, 46 minutes, and 39 seconds equals -9999, which
curiously, is
> > the value we use for missing data. I strongly suspect that we're
> > missing a check for bad data somewhere. When the accumulation
> > interval is bad data (-9999), we should either write out "000000"
or
> > "NA". Using "00000" would likely avoid parsing headaches down the
> > line. But no, I don't think this has anything to do with the bad
object
> output you're getting.
> >
> > Are you able to send me sample files for your MODE run (fcst, obs,
and
> > config file)? I'll run it here, reproduce the behavior you're
seeing,
> > and then try to figure it out. Could you post it to our anonymous
ftp
> site?
> >
> > Being able to replicate the "-02-46-39" will make it easy for me
to
> > fix that one.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA
16
> > WS/WXN via RT <met_help at ucar.edu> wrote:
> >
> > >
> > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > Queue: met_help
> > > Subject: Confusion over MODE .obj Output
> > > Owner: Nobody
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > >
> > >
> > >
> > > Hi,
> > >
> > > I'm trying to figure out if I have a problem with the way I have
> > > configured MODE to run.
> > >
> > > I am attempting to build cloud objects (based on a threshold of
> > > cloud cover being 95% or greater) from DCF cloud model data and
> > > WWMCA ground truth analyses.
> > >
> > > In the example I just ran I have entries in an output .obj file,
one
> > > line for each of the 30 forecast objects, then a line for each
of 26
> > > observation objects, and lines for each of the 30x26
> > forecast-observation pairs.
> > >
> > > Below are a few lines from the output file.
> > >
> > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER
> > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > INTENSITY_10 INTENSITY_25
> > INTENSITY_50
> > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
INTERSECTION_OVER_AREA
> > > COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F002 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F003 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O001 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O002 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O003 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > >
> > > What I can't figure out is how MODE apparently diagnosed 30
forecast
> > > objects and 26 observation objects, but has nothing but zeroes
and
> > > missing values.
> > >
> > > A couple of parts that might be of concern, or help in
diagnosing:
> > >
> > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > indicative of the problem.
> > > 2. The centroid lat/lon of each object is always the same. This
is
> > > a northern hemisphere product and I believe (-20.837,55) is a
corner
> > > point for the WWMCA data. Note that the WWMCA observation data
are
> > > created by WWMCA_REGRID.
> > >
> > > // SIGNED //
> > > Matthew C. Sittel
> > > University Corporation for Atmospheric Research
> > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > matthew.sittel.ctr at us.af.mil
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Tue Jun 14 10:47:59 2016
Thanks John. I didn't know there was a WWMCA "to_grid" pre-
definition. I'm running the code now-hopefully I'll have usable
output shortly. I'll let you know.
Matt
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, June 14, 2016 11:26 AM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Thanks for sending the WWMCA-Regrid config file info. When I used
your settings, I was able to replicate your "bad" result. The WWMCA-
North and WWMCA-South grids are actually predefined in the code and
named "wwma_north" and "wwmca_south". So I updated the "to_grid" in
your config file to read:
to_grid = "wwmca_north";
Then I plotted/attached the result. I also attached the plot of the
forecast data for reference. Notice that the forecast grid is upside-
down and flipped relative to the WWMCA grid. So you will need to use
the "regrid" option when running mode to compare this data. If you
pass the "fcsts_t005..." file as the forecast and the WWMCA data as
the observation, my suggestion would be to regrid to the OBS field.
That way the output will be on the conventional WWMCA North grid.
Please give that a shot and take a close look at both the ascii output
from MODE and the PostScript output.
Hope that helps.
John
On Tue, Jun 14, 2016 at 6:42 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=76735 >
>
> Hi John,
>
> Wow, that WWMCA is way off. Here's how I call it:
>
> ${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file}
-nh
> ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
>
> I pushed the NH and SH WWMCA files to the FTP site for you just now
> (should have thought to do that yesterday).
>
> The config file contents:
>
> regrid = {
> to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47 0
> N";
> vld_thresh = 0.5;
> method = NEAREST;
> width = 1;
> }
>
>
>
//////////////////////////////////////////////////////////////////////
> //////////
>
> //
> // NetCDF output information
> //
> variable_name = "Cloud_Pct";
> units = "percent";
> long_name = "cloud cover percent";
> level = "SFC";
>
>
>
//////////////////////////////////////////////////////////////////////
> //////////
>
> //
> // Maximum pixel age in minutes
> //
> max_minutes = 1440;
>
> I'm guessing I messed up the "to_grid"? I was trying to get it to
> match the model data of course.
>
> Thanks,
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, June 13, 2016 3:50 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> OK, here's what I've found...
>
> (1) wwmca_regrid version 5.1 writes the accumulation interval global
> attribute like this:
> Cloud_Pct:accum_time = "1 hour" ;
>
> The current development version (i.e. for the 5.2 release) writes it
> like
> this:
> Cloud_Pct:accum_time = "010000" ;
> Cloud_Pct:accum_time_sec = 3600 ;
>
> MET actually doesn't even parse the "accum_time" string. Instead,
its
> looking for "accum_time_sec". Since that is missing, the
accumulation
> interval is set to it's default value of bad data (i.e. a value of
-9999).
> We are failing to check for bad data and -9999 is interpreted as a
> number of second and converted to that weird string "-02-46-39".
>
> Version 5.2 of wwmca_regrid will store the accumulation interval in
> the expected way. So it won't have this bad data issue.
>
> However, this is the second time this weird string has popped up.
> I'll add some logic to check for this and write "000000" instead of
"-02-46-39".
>
> (2) I ran plot_data_plane on the data files you sent and have
attached
> the resulting images in PNG format. The GRIB1 forecast looks fine
but
> the WWMCA data does not:
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> fcsts_t005_2016040100_036.GR1 \
> fcsts_t005_2016040100_036_TCDC.ps \
> 'name="TCDC"; level="L0";'
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \ 'name="Cloud_Pct";
> level="(*,*)";'
>
> Notice how weird the WWMCA map data looks. I think we should step
> back and work on the wwmca_regrid output. Can you tell me what
> commands you used to run that one?
>
> FYI, when I ran MODE on this data, I didn't see all the 0's you were
> seeing. I got reasonable looking output. But let's straighten out
> wwmca_regrid before moving on to that.
>
> Thanks,
> John
>
>
>
>
> On Mon, Jun 13, 2016 at 10:31 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=76735 >
> >
> > I just posted the files in 'sittel_data'. This is using the
> > recently recompiled v5.1 executables.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, June 13, 2016 11:18 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > Output
> >
> > Matt,
> >
> > Yes, that certainly doesn't look like very meaningful output from
MODE!
> >
> > Regarding the OBS_ACCUM being set to "-02-46-39", if you do the
math
> > -2 hours, 46 minutes, and 39 seconds equals -9999, which
curiously,
> > is the value we use for missing data. I strongly suspect that
we're
> > missing a check for bad data somewhere. When the accumulation
> > interval is bad data (-9999), we should either write out "000000"
or
> > "NA". Using "00000" would likely avoid parsing headaches down the
> > line. But no, I don't think this has anything to do with the bad
> > object
> output you're getting.
> >
> > Are you able to send me sample files for your MODE run (fcst, obs,
> > and config file)? I'll run it here, reproduce the behavior you're
> > seeing, and then try to figure it out. Could you post it to our
> > anonymous ftp
> site?
> >
> > Being able to replicate the "-02-46-39" will make it easy for me
to
> > fix that one.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA
16
> > WS/WXN via RT <met_help at ucar.edu> wrote:
> >
> > >
> > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > Queue: met_help
> > > Subject: Confusion over MODE .obj Output
> > > Owner: Nobody
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > >
> > >
> > >
> > > Hi,
> > >
> > > I'm trying to figure out if I have a problem with the way I have
> > > configured MODE to run.
> > >
> > > I am attempting to build cloud objects (based on a threshold of
> > > cloud cover being 95% or greater) from DCF cloud model data and
> > > WWMCA ground truth analyses.
> > >
> > > In the example I just ran I have entries in an output .obj file,
> > > one line for each of the 30 forecast objects, then a line for
each
> > > of 26 observation objects, and lines for each of the 30x26
> > forecast-observation pairs.
> > >
> > > Below are a few lines from the output file.
> > >
> > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER
> > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > INTENSITY_10 INTENSITY_25
> > INTENSITY_50
> > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
INTERSECTION_OVER_AREA
> > > COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F002 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F003 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O001 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O002 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O003 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > >
> > > What I can't figure out is how MODE apparently diagnosed 30
> > > forecast objects and 26 observation objects, but has nothing but
> > > zeroes and missing values.
> > >
> > > A couple of parts that might be of concern, or help in
diagnosing:
> > >
> > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > indicative of the problem.
> > > 2. The centroid lat/lon of each object is always the same. This
> > > is a northern hemisphere product and I believe (-20.837,55) is a
> > > corner point for the WWMCA data. Note that the WWMCA
observation
> > > data are created by WWMCA_REGRID.
> > >
> > > // SIGNED //
> > > Matthew C. Sittel
> > > University Corporation for Atmospheric Research
> > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > matthew.sittel.ctr at us.af.mil
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Tue Jun 14 13:48:54 2016
Hey John,
This will sound bizarre, but the only way I can generate meaningful
numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE" in the
MODE config file. When I switch it to "FALSE" I get all zeroes.
Can you replicate on your side? Do I *have* to have that flag on to
force the matching process to even take place? I don't need the ".ps"
output files, just the numbers in ".obj.txt".
Matt
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, June 14, 2016 11:26 AM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Thanks for sending the WWMCA-Regrid config file info. When I used
your settings, I was able to replicate your "bad" result. The WWMCA-
North and WWMCA-South grids are actually predefined in the code and
named "wwma_north" and "wwmca_south". So I updated the "to_grid" in
your config file to read:
to_grid = "wwmca_north";
Then I plotted/attached the result. I also attached the plot of the
forecast data for reference. Notice that the forecast grid is upside-
down and flipped relative to the WWMCA grid. So you will need to use
the "regrid" option when running mode to compare this data. If you
pass the "fcsts_t005..." file as the forecast and the WWMCA data as
the observation, my suggestion would be to regrid to the OBS field.
That way the output will be on the conventional WWMCA North grid.
Please give that a shot and take a close look at both the ascii output
from MODE and the PostScript output.
Hope that helps.
John
On Tue, Jun 14, 2016 at 6:42 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=76735 >
>
> Hi John,
>
> Wow, that WWMCA is way off. Here's how I call it:
>
> ${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file}
-nh
> ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
>
> I pushed the NH and SH WWMCA files to the FTP site for you just now
> (should have thought to do that yesterday).
>
> The config file contents:
>
> regrid = {
> to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47 0
> N";
> vld_thresh = 0.5;
> method = NEAREST;
> width = 1;
> }
>
>
>
//////////////////////////////////////////////////////////////////////
> //////////
>
> //
> // NetCDF output information
> //
> variable_name = "Cloud_Pct";
> units = "percent";
> long_name = "cloud cover percent";
> level = "SFC";
>
>
>
//////////////////////////////////////////////////////////////////////
> //////////
>
> //
> // Maximum pixel age in minutes
> //
> max_minutes = 1440;
>
> I'm guessing I messed up the "to_grid"? I was trying to get it to
> match the model data of course.
>
> Thanks,
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, June 13, 2016 3:50 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> OK, here's what I've found...
>
> (1) wwmca_regrid version 5.1 writes the accumulation interval global
> attribute like this:
> Cloud_Pct:accum_time = "1 hour" ;
>
> The current development version (i.e. for the 5.2 release) writes it
> like
> this:
> Cloud_Pct:accum_time = "010000" ;
> Cloud_Pct:accum_time_sec = 3600 ;
>
> MET actually doesn't even parse the "accum_time" string. Instead,
its
> looking for "accum_time_sec". Since that is missing, the
accumulation
> interval is set to it's default value of bad data (i.e. a value of
-9999).
> We are failing to check for bad data and -9999 is interpreted as a
> number of second and converted to that weird string "-02-46-39".
>
> Version 5.2 of wwmca_regrid will store the accumulation interval in
> the expected way. So it won't have this bad data issue.
>
> However, this is the second time this weird string has popped up.
> I'll add some logic to check for this and write "000000" instead of
"-02-46-39".
>
> (2) I ran plot_data_plane on the data files you sent and have
attached
> the resulting images in PNG format. The GRIB1 forecast looks fine
but
> the WWMCA data does not:
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> fcsts_t005_2016040100_036.GR1 \
> fcsts_t005_2016040100_036_TCDC.ps \
> 'name="TCDC"; level="L0";'
>
> /d1/johnhg/MET/MET_development/
> svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \ 'name="Cloud_Pct";
> level="(*,*)";'
>
> Notice how weird the WWMCA map data looks. I think we should step
> back and work on the wwmca_regrid output. Can you tell me what
> commands you used to run that one?
>
> FYI, when I ran MODE on this data, I didn't see all the 0's you were
> seeing. I got reasonable looking output. But let's straighten out
> wwmca_regrid before moving on to that.
>
> Thanks,
> John
>
>
>
>
> On Mon, Jun 13, 2016 at 10:31 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=76735 >
> >
> > I just posted the files in 'sittel_data'. This is using the
> > recently recompiled v5.1 executables.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, June 13, 2016 11:18 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > Output
> >
> > Matt,
> >
> > Yes, that certainly doesn't look like very meaningful output from
MODE!
> >
> > Regarding the OBS_ACCUM being set to "-02-46-39", if you do the
math
> > -2 hours, 46 minutes, and 39 seconds equals -9999, which
curiously,
> > is the value we use for missing data. I strongly suspect that
we're
> > missing a check for bad data somewhere. When the accumulation
> > interval is bad data (-9999), we should either write out "000000"
or
> > "NA". Using "00000" would likely avoid parsing headaches down the
> > line. But no, I don't think this has anything to do with the bad
> > object
> output you're getting.
> >
> > Are you able to send me sample files for your MODE run (fcst, obs,
> > and config file)? I'll run it here, reproduce the behavior you're
> > seeing, and then try to figure it out. Could you post it to our
> > anonymous ftp
> site?
> >
> > Being able to replicate the "-02-46-39" will make it easy for me
to
> > fix that one.
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA
16
> > WS/WXN via RT <met_help at ucar.edu> wrote:
> >
> > >
> > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > Queue: met_help
> > > Subject: Confusion over MODE .obj Output
> > > Owner: Nobody
> > > Requestors: matthew.sittel.ctr at us.af.mil
> > > Status: new
> > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > >
> > >
> > >
> > > Hi,
> > >
> > > I'm trying to figure out if I have a problem with the way I have
> > > configured MODE to run.
> > >
> > > I am attempting to build cloud objects (based on a threshold of
> > > cloud cover being 95% or greater) from DCF cloud model data and
> > > WWMCA ground truth analyses.
> > >
> > > In the example I just ran I have entries in an output .obj file,
> > > one line for each of the 30 forecast objects, then a line for
each
> > > of 26 observation objects, and lines for each of the 30x26
> > forecast-observation pairs.
> > >
> > > Below are a few lines from the output file.
> > >
> > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_FILTER
> > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > INTENSITY_10 INTENSITY_25
> > INTENSITY_50
> > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
INTERSECTION_OVER_AREA
> > > COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F002 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F003 CF000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O001 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O002 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC O003 CO000 0 0
> > > -20.837 55 0 0 0 0 0
0
> > > 0 0 0 0 0
0
> > > 0 0 0 0 0
> > NA
> > > NA NA NA NA
NA
> > > NA NA NA NA
> > > NA NA
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O001 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O002 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> L0
> > > Cloud_Pct SFC F001_O003 CF000_CO000 NA NA
> NA
> > > NA NA NA NA NA NA
NA
> > > NA NA NA NA NA NA
> > > NA NA NA NA NA
> 0
> > > 0 0 0 0
0
> > > 0 0 0 0
> > > 0 0
> > >
> > > What I can't figure out is how MODE apparently diagnosed 30
> > > forecast objects and 26 observation objects, but has nothing but
> > > zeroes and missing values.
> > >
> > > A couple of parts that might be of concern, or help in
diagnosing:
> > >
> > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > indicative of the problem.
> > > 2. The centroid lat/lon of each object is always the same. This
> > > is a northern hemisphere product and I believe (-20.837,55) is a
> > > corner point for the WWMCA data. Note that the WWMCA
observation
> > > data are created by WWMCA_REGRID.
> > >
> > > // SIGNED //
> > > Matthew C. Sittel
> > > University Corporation for Atmospheric Research
> > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > matthew.sittel.ctr at us.af.mil
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Tue Jun 14 14:38:15 2016
Matt,
Wow, that is a very odd symptom! I just reran your case twice with
"ps_plot_flag" set to TRUE and FALSE.
I compared the output "_obj.txt" files and found them to be identical.
Are you positive that the only configuration file change you made was
in
ps_plot_flag? If you're using environment variables in the config
file,
please check their values to make sure they are set as you intended.
So I'm not able to replicate the behavior you describe using the
latest
met-5.1 bugfix release.
Thanks,
John
On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
>
> Hey John,
>
> This will sound bizarre, but the only way I can generate meaningful
> numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE" in
the MODE
> config file. When I switch it to "FALSE" I get all zeroes.
>
> Can you replicate on your side? Do I *have* to have that flag on to
force
> the matching process to even take place? I don't need the ".ps"
output
> files, just the numbers in ".obj.txt".
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, June 14, 2016 11:26 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Thanks for sending the WWMCA-Regrid config file info. When I used
your
> settings, I was able to replicate your "bad" result. The WWMCA-
North and
> WWMCA-South grids are actually predefined in the code and named
> "wwma_north" and "wwmca_south". So I updated the "to_grid" in your
config
> file to read:
> to_grid = "wwmca_north";
>
> Then I plotted/attached the result. I also attached the plot of the
> forecast data for reference. Notice that the forecast grid is
upside-down
> and flipped relative to the WWMCA grid. So you will need to use the
> "regrid" option when running mode to compare this data. If you pass
the
> "fcsts_t005..." file as the forecast and the WWMCA data as the
observation,
> my suggestion would be to regrid to the OBS field. That way the
output
> will be on the conventional WWMCA North grid.
>
> Please give that a shot and take a close look at both the ascii
output
> from MODE and the PostScript output.
>
> Hope that helps.
>
> John
>
>
> On Tue, Jun 14, 2016 at 6:42 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=76735 >
> >
> > Hi John,
> >
> > Wow, that WWMCA is way off. Here's how I call it:
> >
> > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file}
-nh
> > ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
> >
> > I pushed the NH and SH WWMCA files to the FTP site for you just
now
> > (should have thought to do that yesterday).
> >
> > The config file contents:
> >
> > regrid = {
> > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47 0
> > N";
> > vld_thresh = 0.5;
> > method = NEAREST;
> > width = 1;
> > }
> >
> >
> >
//////////////////////////////////////////////////////////////////////
> > //////////
> >
> > //
> > // NetCDF output information
> > //
> > variable_name = "Cloud_Pct";
> > units = "percent";
> > long_name = "cloud cover percent";
> > level = "SFC";
> >
> >
> >
//////////////////////////////////////////////////////////////////////
> > //////////
> >
> > //
> > // Maximum pixel age in minutes
> > //
> > max_minutes = 1440;
> >
> > I'm guessing I messed up the "to_grid"? I was trying to get it to
> > match the model data of course.
> >
> > Thanks,
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, June 13, 2016 3:50 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
> >
> > Matt,
> >
> > OK, here's what I've found...
> >
> > (1) wwmca_regrid version 5.1 writes the accumulation interval
global
> > attribute like this:
> > Cloud_Pct:accum_time = "1 hour" ;
> >
> > The current development version (i.e. for the 5.2 release) writes
it
> > like
> > this:
> > Cloud_Pct:accum_time = "010000" ;
> > Cloud_Pct:accum_time_sec = 3600 ;
> >
> > MET actually doesn't even parse the "accum_time" string. Instead,
its
> > looking for "accum_time_sec". Since that is missing, the
accumulation
> > interval is set to it's default value of bad data (i.e. a value of
> -9999).
> > We are failing to check for bad data and -9999 is interpreted as a
> > number of second and converted to that weird string "-02-46-39".
> >
> > Version 5.2 of wwmca_regrid will store the accumulation interval
in
> > the expected way. So it won't have this bad data issue.
> >
> > However, this is the second time this weird string has popped up.
> > I'll add some logic to check for this and write "000000" instead
of
> "-02-46-39".
> >
> > (2) I ran plot_data_plane on the data files you sent and have
attached
> > the resulting images in PNG format. The GRIB1 forecast looks fine
but
> > the WWMCA data does not:
> >
> > /d1/johnhg/MET/MET_development/
> > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > fcsts_t005_2016040100_036.GR1 \
> > fcsts_t005_2016040100_036_TCDC.ps \
> > 'name="TCDC"; level="L0";'
> >
> > /d1/johnhg/MET/MET_development/
> > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
'name="Cloud_Pct";
> > level="(*,*)";'
> >
> > Notice how weird the WWMCA map data looks. I think we should step
> > back and work on the wwmca_regrid output. Can you tell me what
> > commands you used to run that one?
> >
> > FYI, when I ran MODE on this data, I didn't see all the 0's you
were
> > seeing. I got reasonable looking output. But let's straighten
out
> > wwmca_regrid before moving on to that.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Mon, Jun 13, 2016 at 10:31 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=76735 >
> > >
> > > I just posted the files in 'sittel_data'. This is using the
> > > recently recompiled v5.1 executables.
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, June 13, 2016 11:18 AM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > Yes, that certainly doesn't look like very meaningful output
from MODE!
> > >
> > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do the
math
> > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
curiously,
> > > is the value we use for missing data. I strongly suspect that
we're
> > > missing a check for bad data somewhere. When the accumulation
> > > interval is bad data (-9999), we should either write out
"000000" or
> > > "NA". Using "00000" would likely avoid parsing headaches down
the
> > > line. But no, I don't think this has anything to do with the
bad
> > > object
> > output you're getting.
> > >
> > > Are you able to send me sample files for your MODE run (fcst,
obs,
> > > and config file)? I'll run it here, reproduce the behavior
you're
> > > seeing, and then try to figure it out. Could you post it to our
> > > anonymous ftp
> > site?
> > >
> > > Being able to replicate the "-02-46-39" will make it easy for me
to
> > > fix that one.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA
16
> > > WS/WXN via RT <met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > > Queue: met_help
> > > > Subject: Confusion over MODE .obj Output
> > > > Owner: Nobody
> > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > Status: new
> > > > Ticket <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to figure out if I have a problem with the way I
have
> > > > configured MODE to run.
> > > >
> > > > I am attempting to build cloud objects (based on a threshold
of
> > > > cloud cover being 95% or greater) from DCF cloud model data
and
> > > > WWMCA ground truth analyses.
> > > >
> > > > In the example I just ran I have entries in an output .obj
file,
> > > > one line for each of the 30 forecast objects, then a line for
each
> > > > of 26 observation objects, and lines for each of the 30x26
> > > forecast-observation pairs.
> > > >
> > > > Below are a few lines from the output file.
> > > >
> > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA
AREA_FILTER
> > > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > > INTENSITY_10 INTENSITY_25
> > > INTENSITY_50
> > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
INTERSECTION_OVER_AREA
> > > > COMPLEXITY_RATIO PERCENTILE_INTENSITY_RATIO INTEREST
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F002 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F003 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O001 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O002 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O003 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > >
> > > > What I can't figure out is how MODE apparently diagnosed 30
> > > > forecast objects and 26 observation objects, but has nothing
but
> > > > zeroes and missing values.
> > > >
> > > > A couple of parts that might be of concern, or help in
diagnosing:
> > > >
> > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > > indicative of the problem.
> > > > 2. The centroid lat/lon of each object is always the same.
This
> > > > is a northern hemisphere product and I believe (-20.837,55) is
a
> > > > corner point for the WWMCA data. Note that the WWMCA
observation
> > > > data are created by WWMCA_REGRID.
> > > >
> > > > // SIGNED //
> > > > Matthew C. Sittel
> > > > University Corporation for Atmospheric Research
> > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > > matthew.sittel.ctr at us.af.mil
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Wed Jun 15 07:56:29 2016
I'm positive. That was the only change I made between runs. I did it
multiple times yesterday and today to convince myself that was the
reason.
Can you think of anything in the the MODE config file that would force
such a dependency?
It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I need
to run 480 verifications, so I'll never get this done in a reasonable
amount of time. While I may drop some forecast hours if no solution
can be found, a solution would be even better as it seems the longest
step is that PostScript build.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, June 14, 2016 3:38 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Wow, that is a very odd symptom! I just reran your case twice with
"ps_plot_flag" set to TRUE and FALSE.
I compared the output "_obj.txt" files and found them to be identical.
Are you positive that the only configuration file change you made was
in ps_plot_flag? If you're using environment variables in the config
file, please check their values to make sure they are set as you
intended.
So I'm not able to replicate the behavior you describe using the
latest
met-5.1 bugfix release.
Thanks,
John
On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
>
> Hey John,
>
> This will sound bizarre, but the only way I can generate meaningful
> numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE" in
the
> MODE config file. When I switch it to "FALSE" I get all zeroes.
>
> Can you replicate on your side? Do I *have* to have that flag on to
> force the matching process to even take place? I don't need the
".ps"
> output files, just the numbers in ".obj.txt".
>
> Matt
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, June 14, 2016 11:26 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Thanks for sending the WWMCA-Regrid config file info. When I used
> your settings, I was able to replicate your "bad" result. The
> WWMCA-North and WWMCA-South grids are actually predefined in the
code
> and named "wwma_north" and "wwmca_south". So I updated the
"to_grid"
> in your config file to read:
> to_grid = "wwmca_north";
>
> Then I plotted/attached the result. I also attached the plot of the
> forecast data for reference. Notice that the forecast grid is
> upside-down and flipped relative to the WWMCA grid. So you will
need
> to use the "regrid" option when running mode to compare this data.
If
> you pass the "fcsts_t005..." file as the forecast and the WWMCA data
> as the observation, my suggestion would be to regrid to the OBS
field.
> That way the output will be on the conventional WWMCA North grid.
>
> Please give that a shot and take a close look at both the ascii
output
> from MODE and the PostScript output.
>
> Hope that helps.
>
> John
>
>
> On Tue, Jun 14, 2016 at 6:42 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=76735 >
> >
> > Hi John,
> >
> > Wow, that WWMCA is way off. Here's how I call it:
> >
> > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config ${regrid_cfg_file}
> > -nh ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
> >
> > I pushed the NH and SH WWMCA files to the FTP site for you just
now
> > (should have thought to do that yesterday).
> >
> > The config file contents:
> >
> > regrid = {
> > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47 0
> > N";
> > vld_thresh = 0.5;
> > method = NEAREST;
> > width = 1;
> > }
> >
> >
> >
////////////////////////////////////////////////////////////////////
> > //
> > //////////
> >
> > //
> > // NetCDF output information
> > //
> > variable_name = "Cloud_Pct";
> > units = "percent";
> > long_name = "cloud cover percent";
> > level = "SFC";
> >
> >
> >
////////////////////////////////////////////////////////////////////
> > //
> > //////////
> >
> > //
> > // Maximum pixel age in minutes
> > //
> > max_minutes = 1440;
> >
> > I'm guessing I messed up the "to_grid"? I was trying to get it to
> > match the model data of course.
> >
> > Thanks,
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Monday, June 13, 2016 3:50 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > Output
> >
> > Matt,
> >
> > OK, here's what I've found...
> >
> > (1) wwmca_regrid version 5.1 writes the accumulation interval
global
> > attribute like this:
> > Cloud_Pct:accum_time = "1 hour" ;
> >
> > The current development version (i.e. for the 5.2 release) writes
it
> > like
> > this:
> > Cloud_Pct:accum_time = "010000" ;
> > Cloud_Pct:accum_time_sec = 3600 ;
> >
> > MET actually doesn't even parse the "accum_time" string. Instead,
> > its looking for "accum_time_sec". Since that is missing, the
> > accumulation interval is set to it's default value of bad data
(i.e.
> > a value of
> -9999).
> > We are failing to check for bad data and -9999 is interpreted as a
> > number of second and converted to that weird string "-02-46-39".
> >
> > Version 5.2 of wwmca_regrid will store the accumulation interval
in
> > the expected way. So it won't have this bad data issue.
> >
> > However, this is the second time this weird string has popped up.
> > I'll add some logic to check for this and write "000000" instead
of
> "-02-46-39".
> >
> > (2) I ran plot_data_plane on the data files you sent and have
> > attached the resulting images in PNG format. The GRIB1 forecast
> > looks fine but the WWMCA data does not:
> >
> > /d1/johnhg/MET/MET_development/
> > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > fcsts_t005_2016040100_036.GR1 \
> > fcsts_t005_2016040100_036_TCDC.ps \
> > 'name="TCDC"; level="L0";'
> >
> > /d1/johnhg/MET/MET_development/
> > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
'name="Cloud_Pct";
> > level="(*,*)";'
> >
> > Notice how weird the WWMCA map data looks. I think we should step
> > back and work on the wwmca_regrid output. Can you tell me what
> > commands you used to run that one?
> >
> > FYI, when I ran MODE on this data, I didn't see all the 0's you
were
> > seeing. I got reasonable looking output. But let's straighten
out
> > wwmca_regrid before moving on to that.
> >
> > Thanks,
> > John
> >
> >
> >
> >
> > On Mon, Jun 13, 2016 at 10:31 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=76735 >
> > >
> > > I just posted the files in 'sittel_data'. This is using the
> > > recently recompiled v5.1 executables.
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, June 13, 2016 11:18 AM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > Yes, that certainly doesn't look like very meaningful output
from MODE!
> > >
> > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do the
> > > math
> > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > curiously, is the value we use for missing data. I strongly
> > > suspect that we're missing a check for bad data somewhere. When
> > > the accumulation interval is bad data (-9999), we should either
> > > write out "000000" or "NA". Using "00000" would likely avoid
> > > parsing headaches down the line. But no, I don't think this has
> > > anything to do with the bad object
> > output you're getting.
> > >
> > > Are you able to send me sample files for your MODE run (fcst,
obs,
> > > and config file)? I'll run it here, reproduce the behavior
you're
> > > seeing, and then try to figure it out. Could you post it to our
> > > anonymous ftp
> > site?
> > >
> > > Being able to replicate the "-02-46-39" will make it easy for me
> > > to fix that one.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF AFWA
> > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > > Queue: met_help
> > > > Subject: Confusion over MODE .obj Output
> > > > Owner: Nobody
> > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > Status: new
> > > > Ticket <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to figure out if I have a problem with the way I
have
> > > > configured MODE to run.
> > > >
> > > > I am attempting to build cloud objects (based on a threshold
of
> > > > cloud cover being 95% or greater) from DCF cloud model data
and
> > > > WWMCA ground truth analyses.
> > > >
> > > > In the example I just ran I have entries in an output .obj
file,
> > > > one line for each of the 30 forecast objects, then a line for
> > > > each of 26 observation objects, and lines for each of the
30x26
> > > forecast-observation pairs.
> > > >
> > > > Below are a few lines from the output file.
> > > >
> > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
OBS_VALID
> > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR FCST_LEV
> > > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA
AREA_FILTER
> > > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > > INTENSITY_10 INTENSITY_25
> > > INTENSITY_50
> > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST
> > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
PERCENTILE_INTENSITY_RATIO INTEREST
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F002 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F003 CF000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O001 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O002 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC O003 CO000 0
0
> > > > -20.837 55 0 0 0 0 0
> 0
> > > > 0 0 0 0 0
0
> > > > 0 0 0 0 0
> > > NA
> > > > NA NA NA NA
NA
> > > > NA NA NA NA
> > > > NA NA
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > L0
> > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > NA
> > > > NA NA NA NA NA NA
NA
> > > > NA NA NA NA NA
NA
> > > > NA NA NA NA NA
> > 0
> > > > 0 0 0 0
0
> > > > 0 0 0 0
> > > > 0 0
> > > >
> > > > What I can't figure out is how MODE apparently diagnosed 30
> > > > forecast objects and 26 observation objects, but has nothing
but
> > > > zeroes and missing values.
> > > >
> > > > A couple of parts that might be of concern, or help in
diagnosing:
> > > >
> > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > > indicative of the problem.
> > > > 2. The centroid lat/lon of each object is always the same.
This
> > > > is a northern hemisphere product and I believe (-20.837,55) is
a
> > > > corner point for the WWMCA data. Note that the WWMCA
> > > > observation data are created by WWMCA_REGRID.
> > > >
> > > > // SIGNED //
> > > > Matthew C. Sittel
> > > > University Corporation for Atmospheric Research
> > > > 16 WS/WXN, 557 WW, Offutt AFB, NE matthew.sittel.ctr at us.af.mil
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Wed Jun 15 10:38:40 2016
Matt,
Yes, that is very odd behavior.
Let's clarify out exactly what version of MET you're running. I know
it's
version 5.1, but what is the date of the latest patches you've
applied?
Also, didn't I send you updates for wwmca_regrid? Are those also
applied?
Lastly, can you send me the config.log file in your top-level MET
directory? That'll tell me the compilers used and options compiled.
Thanks,
John
On Wed, Jun 15, 2016 at 7:56 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=76735 >
>
> I'm positive. That was the only change I made between runs. I did
it
> multiple times yesterday and today to convince myself that was the
reason.
>
> Can you think of anything in the the MODE config file that would
force
> such a dependency?
>
> It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I need
to
> run 480 verifications, so I'll never get this done in a reasonable
amount
> of time. While I may drop some forecast hours if no solution can be
found,
> a solution would be even better as it seems the longest step is that
> PostScript build.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, June 14, 2016 3:38 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Wow, that is a very odd symptom! I just reran your case twice with
> "ps_plot_flag" set to TRUE and FALSE.
>
> I compared the output "_obj.txt" files and found them to be
identical.
>
> Are you positive that the only configuration file change you made
was in
> ps_plot_flag? If you're using environment variables in the config
file,
> please check their values to make sure they are set as you intended.
>
> So I'm not able to replicate the behavior you describe using the
latest
> met-5.1 bugfix release.
>
> Thanks,
> John
>
> On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
> >
> > Hey John,
> >
> > This will sound bizarre, but the only way I can generate
meaningful
> > numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE" in
the
> > MODE config file. When I switch it to "FALSE" I get all zeroes.
> >
> > Can you replicate on your side? Do I *have* to have that flag on
to
> > force the matching process to even take place? I don't need the
".ps"
> > output files, just the numbers in ".obj.txt".
> >
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, June 14, 2016 11:26 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
> >
> > Matt,
> >
> > Thanks for sending the WWMCA-Regrid config file info. When I used
> > your settings, I was able to replicate your "bad" result. The
> > WWMCA-North and WWMCA-South grids are actually predefined in the
code
> > and named "wwma_north" and "wwmca_south". So I updated the
"to_grid"
> > in your config file to read:
> > to_grid = "wwmca_north";
> >
> > Then I plotted/attached the result. I also attached the plot of
the
> > forecast data for reference. Notice that the forecast grid is
> > upside-down and flipped relative to the WWMCA grid. So you will
need
> > to use the "regrid" option when running mode to compare this data.
If
> > you pass the "fcsts_t005..." file as the forecast and the WWMCA
data
> > as the observation, my suggestion would be to regrid to the OBS
field.
> > That way the output will be on the conventional WWMCA North grid.
> >
> > Please give that a shot and take a close look at both the ascii
output
> > from MODE and the PostScript output.
> >
> > Hope that helps.
> >
> > John
> >
> >
> > On Tue, Jun 14, 2016 at 6:42 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=76735 >
> > >
> > > Hi John,
> > >
> > > Wow, that WWMCA is way off. Here's how I call it:
> > >
> > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
${regrid_cfg_file}
> > > -nh ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
> > >
> > > I pushed the NH and SH WWMCA files to the FTP site for you just
now
> > > (should have thought to do that yesterday).
> > >
> > > The config file contents:
> > >
> > > regrid = {
> > > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47
> 0
> > > N";
> > > vld_thresh = 0.5;
> > > method = NEAREST;
> > > width = 1;
> > > }
> > >
> > >
> > >
////////////////////////////////////////////////////////////////////
> > > //
> > > //////////
> > >
> > > //
> > > // NetCDF output information
> > > //
> > > variable_name = "Cloud_Pct";
> > > units = "percent";
> > > long_name = "cloud cover percent";
> > > level = "SFC";
> > >
> > >
> > >
////////////////////////////////////////////////////////////////////
> > > //
> > > //////////
> > >
> > > //
> > > // Maximum pixel age in minutes
> > > //
> > > max_minutes = 1440;
> > >
> > > I'm guessing I messed up the "to_grid"? I was trying to get it
to
> > > match the model data of course.
> > >
> > > Thanks,
> > > Matt
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, June 13, 2016 3:50 PM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > OK, here's what I've found...
> > >
> > > (1) wwmca_regrid version 5.1 writes the accumulation interval
global
> > > attribute like this:
> > > Cloud_Pct:accum_time = "1 hour" ;
> > >
> > > The current development version (i.e. for the 5.2 release)
writes it
> > > like
> > > this:
> > > Cloud_Pct:accum_time = "010000" ;
> > > Cloud_Pct:accum_time_sec = 3600 ;
> > >
> > > MET actually doesn't even parse the "accum_time" string.
Instead,
> > > its looking for "accum_time_sec". Since that is missing, the
> > > accumulation interval is set to it's default value of bad data
(i.e.
> > > a value of
> > -9999).
> > > We are failing to check for bad data and -9999 is interpreted as
a
> > > number of second and converted to that weird string "-02-46-39".
> > >
> > > Version 5.2 of wwmca_regrid will store the accumulation interval
in
> > > the expected way. So it won't have this bad data issue.
> > >
> > > However, this is the second time this weird string has popped
up.
> > > I'll add some logic to check for this and write "000000" instead
of
> > "-02-46-39".
> > >
> > > (2) I ran plot_data_plane on the data files you sent and have
> > > attached the resulting images in PNG format. The GRIB1 forecast
> > > looks fine but the WWMCA data does not:
> > >
> > > /d1/johnhg/MET/MET_development/
> > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > fcsts_t005_2016040100_036.GR1 \
> > > fcsts_t005_2016040100_036_TCDC.ps \
> > > 'name="TCDC"; level="L0";'
> > >
> > > /d1/johnhg/MET/MET_development/
> > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
'name="Cloud_Pct";
> > > level="(*,*)";'
> > >
> > > Notice how weird the WWMCA map data looks. I think we should
step
> > > back and work on the wwmca_regrid output. Can you tell me what
> > > commands you used to run that one?
> > >
> > > FYI, when I ran MODE on this data, I didn't see all the 0's you
were
> > > seeing. I got reasonable looking output. But let's straighten
out
> > > wwmca_regrid before moving on to that.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > >
> > > On Mon, Jun 13, 2016 at 10:31 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=76735
>
> > > >
> > > > I just posted the files in 'sittel_data'. This is using the
> > > > recently recompiled v5.1 executables.
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, June 13, 2016 11:18 AM
> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > matthew.sittel.ctr at us.af.mil>
> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > > Output
> > > >
> > > > Matt,
> > > >
> > > > Yes, that certainly doesn't look like very meaningful output
from
> MODE!
> > > >
> > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do
the
> > > > math
> > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > > curiously, is the value we use for missing data. I strongly
> > > > suspect that we're missing a check for bad data somewhere.
When
> > > > the accumulation interval is bad data (-9999), we should
either
> > > > write out "000000" or "NA". Using "00000" would likely avoid
> > > > parsing headaches down the line. But no, I don't think this
has
> > > > anything to do with the bad object
> > > output you're getting.
> > > >
> > > > Are you able to send me sample files for your MODE run (fcst,
obs,
> > > > and config file)? I'll run it here, reproduce the behavior
you're
> > > > seeing, and then try to figure it out. Could you post it to
our
> > > > anonymous ftp
> > > site?
> > > >
> > > > Being able to replicate the "-02-46-39" will make it easy for
me
> > > > to fix that one.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF
AFWA
> > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > > > Queue: met_help
> > > > > Subject: Confusion over MODE .obj Output
> > > > > Owner: Nobody
> > > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > > Status: new
> > > > > Ticket <URL:
> > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm trying to figure out if I have a problem with the way I
have
> > > > > configured MODE to run.
> > > > >
> > > > > I am attempting to build cloud objects (based on a threshold
of
> > > > > cloud cover being 95% or greater) from DCF cloud model data
and
> > > > > WWMCA ground truth analyses.
> > > > >
> > > > > In the example I just ran I have entries in an output .obj
file,
> > > > > one line for each of the 30 forecast objects, then a line
for
> > > > > each of 26 observation objects, and lines for each of the
30x26
> > > > forecast-observation pairs.
> > > > >
> > > > > Below are a few lines from the output file.
> > > > >
> > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
> OBS_VALID
> > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
FCST_LEV
> > > > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA
AREA_FILTER
> > > > > AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y COMPLEXITY
> > > > > INTENSITY_10 INTENSITY_25
> > > > INTENSITY_50
> > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
> CENTROID_DIST
> > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
PERCENTILE_INTENSITY_RATIO
> INTEREST
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F002 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F003 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O001 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O002 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O003 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > >
> > > > > What I can't figure out is how MODE apparently diagnosed 30
> > > > > forecast objects and 26 observation objects, but has nothing
but
> > > > > zeroes and missing values.
> > > > >
> > > > > A couple of parts that might be of concern, or help in
diagnosing:
> > > > >
> > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > > > indicative of the problem.
> > > > > 2. The centroid lat/lon of each object is always the same.
This
> > > > > is a northern hemisphere product and I believe (-20.837,55)
is a
> > > > > corner point for the WWMCA data. Note that the WWMCA
> > > > > observation data are created by WWMCA_REGRID.
> > > > >
> > > > > // SIGNED //
> > > > > Matthew C. Sittel
> > > > > University Corporation for Atmospheric Research
> > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
matthew.sittel.ctr at us.af.mil
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Wed Jun 15 11:10:28 2016
Yes it's 5.1 with the May 23 patches applied.
Config log attached.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, June 15, 2016 11:39 AM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Yes, that is very odd behavior.
Let's clarify out exactly what version of MET you're running. I know
it's
version 5.1, but what is the date of the latest patches you've
applied?
Also, didn't I send you updates for wwmca_regrid? Are those also
applied?
Lastly, can you send me the config.log file in your top-level MET
directory?
That'll tell me the compilers used and options compiled.
Thanks,
John
On Wed, Jun 15, 2016 at 7:56 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=76735 >
>
> I'm positive. That was the only change I made between runs. I did
it
> multiple times yesterday and today to convince myself that was the
reason.
>
> Can you think of anything in the the MODE config file that would
force
> such a dependency?
>
> It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I need
> to run 480 verifications, so I'll never get this done in a
reasonable
> amount of time. While I may drop some forecast hours if no solution
> can be found, a solution would be even better as it seems the
longest
> step is that PostScript build.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, June 14, 2016 3:38 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Wow, that is a very odd symptom! I just reran your case twice with
> "ps_plot_flag" set to TRUE and FALSE.
>
> I compared the output "_obj.txt" files and found them to be
identical.
>
> Are you positive that the only configuration file change you made
was
> in ps_plot_flag? If you're using environment variables in the
config
> file, please check their values to make sure they are set as you
intended.
>
> So I'm not able to replicate the behavior you describe using the
> latest
> met-5.1 bugfix release.
>
> Thanks,
> John
>
> On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
> >
> > Hey John,
> >
> > This will sound bizarre, but the only way I can generate
meaningful
> > numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE" in
> > the MODE config file. When I switch it to "FALSE" I get all
zeroes.
> >
> > Can you replicate on your side? Do I *have* to have that flag on
to
> > force the matching process to even take place? I don't need the
".ps"
> > output files, just the numbers in ".obj.txt".
> >
> > Matt
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, June 14, 2016 11:26 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > Output
> >
> > Matt,
> >
> > Thanks for sending the WWMCA-Regrid config file info. When I used
> > your settings, I was able to replicate your "bad" result. The
> > WWMCA-North and WWMCA-South grids are actually predefined in the
> > code and named "wwma_north" and "wwmca_south". So I updated the
"to_grid"
> > in your config file to read:
> > to_grid = "wwmca_north";
> >
> > Then I plotted/attached the result. I also attached the plot of
the
> > forecast data for reference. Notice that the forecast grid is
> > upside-down and flipped relative to the WWMCA grid. So you will
> > need to use the "regrid" option when running mode to compare this
> > data. If you pass the "fcsts_t005..." file as the forecast and
the
> > WWMCA data as the observation, my suggestion would be to regrid to
the OBS
> > field.
> > That way the output will be on the conventional WWMCA North grid.
> >
> > Please give that a shot and take a close look at both the ascii
> > output from MODE and the PostScript output.
> >
> > Hope that helps.
> >
> > John
> >
> >
> > On Tue, Jun 14, 2016 at 6:42 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=76735 >
> > >
> > > Hi John,
> > >
> > > Wow, that WWMCA is way off. Here's how I call it:
> > >
> > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
${regrid_cfg_file}
> > > -nh ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
> > >
> > > I pushed the NH and SH WWMCA files to the FTP site for you just
> > > now (should have thought to do that yesterday).
> > >
> > > The config file contents:
> > >
> > > regrid = {
> > > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
6367.47
> 0
> > > N";
> > > vld_thresh = 0.5;
> > > method = NEAREST;
> > > width = 1;
> > > }
> > >
> > >
> > >
//////////////////////////////////////////////////////////////////
> > > //
> > > //
> > > //////////
> > >
> > > //
> > > // NetCDF output information
> > > //
> > > variable_name = "Cloud_Pct";
> > > units = "percent";
> > > long_name = "cloud cover percent";
> > > level = "SFC";
> > >
> > >
> > >
//////////////////////////////////////////////////////////////////
> > > //
> > > //
> > > //////////
> > >
> > > //
> > > // Maximum pixel age in minutes
> > > //
> > > max_minutes = 1440;
> > >
> > > I'm guessing I messed up the "to_grid"? I was trying to get it
to
> > > match the model data of course.
> > >
> > > Thanks,
> > > Matt
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Monday, June 13, 2016 3:50 PM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > OK, here's what I've found...
> > >
> > > (1) wwmca_regrid version 5.1 writes the accumulation interval
> > > global attribute like this:
> > > Cloud_Pct:accum_time = "1 hour" ;
> > >
> > > The current development version (i.e. for the 5.2 release)
writes
> > > it like
> > > this:
> > > Cloud_Pct:accum_time = "010000" ;
> > > Cloud_Pct:accum_time_sec = 3600 ;
> > >
> > > MET actually doesn't even parse the "accum_time" string.
Instead,
> > > its looking for "accum_time_sec". Since that is missing, the
> > > accumulation interval is set to it's default value of bad data
(i.e.
> > > a value of
> > -9999).
> > > We are failing to check for bad data and -9999 is interpreted as
a
> > > number of second and converted to that weird string "-02-46-39".
> > >
> > > Version 5.2 of wwmca_regrid will store the accumulation interval
> > > in the expected way. So it won't have this bad data issue.
> > >
> > > However, this is the second time this weird string has popped
up.
> > > I'll add some logic to check for this and write "000000" instead
> > > of
> > "-02-46-39".
> > >
> > > (2) I ran plot_data_plane on the data files you sent and have
> > > attached the resulting images in PNG format. The GRIB1 forecast
> > > looks fine but the WWMCA data does not:
> > >
> > > /d1/johnhg/MET/MET_development/
> > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > fcsts_t005_2016040100_036.GR1 \
> > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC"; level="L0";'
> > >
> > > /d1/johnhg/MET/MET_development/
> > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
> > > 'name="Cloud_Pct"; level="(*,*)";'
> > >
> > > Notice how weird the WWMCA map data looks. I think we should
step
> > > back and work on the wwmca_regrid output. Can you tell me what
> > > commands you used to run that one?
> > >
> > > FYI, when I ran MODE on this data, I didn't see all the 0's you
> > > were seeing. I got reasonable looking output. But let's
> > > straighten out wwmca_regrid before moving on to that.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > >
> > > On Mon, Jun 13, 2016 at 10:31 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=76735
>
> > > >
> > > > I just posted the files in 'sittel_data'. This is using the
> > > > recently recompiled v5.1 executables.
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, June 13, 2016 11:18 AM
> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > matthew.sittel.ctr at us.af.mil>
> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > > Output
> > > >
> > > > Matt,
> > > >
> > > > Yes, that certainly doesn't look like very meaningful output
> > > > from
> MODE!
> > > >
> > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do
the
> > > > math
> > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > > curiously, is the value we use for missing data. I strongly
> > > > suspect that we're missing a check for bad data somewhere.
When
> > > > the accumulation interval is bad data (-9999), we should
either
> > > > write out "000000" or "NA". Using "00000" would likely avoid
> > > > parsing headaches down the line. But no, I don't think this
has
> > > > anything to do with the bad object
> > > output you're getting.
> > > >
> > > > Are you able to send me sample files for your MODE run (fcst,
> > > > obs, and config file)? I'll run it here, reproduce the
behavior
> > > > you're seeing, and then try to figure it out. Could you post
it
> > > > to our anonymous ftp
> > > site?
> > > >
> > > > Being able to replicate the "-02-46-39" will make it easy for
me
> > > > to fix that one.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF
AFWA
> > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > > Transaction: Ticket created by matthew.sittel.ctr at us.af.mil
> > > > > Queue: met_help
> > > > > Subject: Confusion over MODE .obj Output
> > > > > Owner: Nobody
> > > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > > Status: new
> > > > > Ticket <URL:
> > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm trying to figure out if I have a problem with the way I
> > > > > have configured MODE to run.
> > > > >
> > > > > I am attempting to build cloud objects (based on a threshold
> > > > > of cloud cover being 95% or greater) from DCF cloud model
data
> > > > > and WWMCA ground truth analyses.
> > > > >
> > > > > In the example I just ran I have entries in an output .obj
> > > > > file, one line for each of the 30 forecast objects, then a
> > > > > line for each of 26 observation objects, and lines for each
of
> > > > > the 30x26
> > > > forecast-observation pairs.
> > > > >
> > > > > Below are a few lines from the output file.
> > > > >
> > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM OBS_LEAD
> OBS_VALID
> > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
FCST_LEV
> > > > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y
> > > > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA
> > > > > AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y
> > > > > COMPLEXITY
> > > > > INTENSITY_10 INTENSITY_25
> > > > INTENSITY_50
> > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
> CENTROID_DIST
> > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> > > > > PERCENTILE_INTENSITY_RATIO
> INTEREST
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F002 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F003 CF000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O001 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O002 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC O003 CO000 0
0
> > > > > -20.837 55 0 0 0 0 0
> > 0
> > > > > 0 0 0 0 0
0
> > > > > 0 0 0 0 0
> > > > NA
> > > > > NA NA NA NA
> NA
> > > > > NA NA NA NA
> > > > > NA NA
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > 20160402_120000 -02-46-39 8 >=95.0 8 >=95.0
TCDC
> > > L0
> > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > > NA
> > > > > NA NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
NA
> > > > > NA NA NA NA NA
> > > 0
> > > > > 0 0 0 0
0
> > > > > 0 0 0 0
> > > > > 0 0
> > > > >
> > > > > What I can't figure out is how MODE apparently diagnosed 30
> > > > > forecast objects and 26 observation objects, but has nothing
> > > > > but zeroes and missing values.
> > > > >
> > > > > A couple of parts that might be of concern, or help in
diagnosing:
> > > > >
> > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it is
> > > > > indicative of the problem.
> > > > > 2. The centroid lat/lon of each object is always the same.
> > > > > This is a northern hemisphere product and I believe
> > > > > (-20.837,55) is a corner point for the WWMCA data. Note
that
> > > > > the WWMCA observation data are created by WWMCA_REGRID.
> > > > >
> > > > > // SIGNED //
> > > > > Matthew C. Sittel
> > > > > University Corporation for Atmospheric Research
> > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
matthew.sittel.ctr at us.af.mil
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Wed Jun 15 11:48:14 2016
Matt,
Great, thanks.
Sorry to ask for so much data on this, but it would also be helpful
see the
two version of the output "_obj.txt" file. The one generated with
ps_flag
= TRUE and the other one with ps_flag = FALSE.
As for timing information, I'm surprised there is that large of a
discrepancy between the two. When I run your test case, running with
ps_flag = TRUE takes 4:25 while running with ps_flag = FALSE takes
3:58.
27 seconds is a significant difference, but represents only about a
10%
runtime difference.
You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
What is
it with ps_flag = FALSE?
Thanks,
John
On Wed, Jun 15, 2016 at 11:10 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=76735 >
>
> Yes it's 5.1 with the May 23 patches applied.
>
> Config log attached.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, June 15, 2016 11:39 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
> <matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Yes, that is very odd behavior.
>
> Let's clarify out exactly what version of MET you're running. I
know it's
> version 5.1, but what is the date of the latest patches you've
applied?
> Also, didn't I send you updates for wwmca_regrid? Are those also
applied?
>
> Lastly, can you send me the config.log file in your top-level MET
> directory?
> That'll tell me the compilers used and options compiled.
>
> Thanks,
> John
>
> On Wed, Jun 15, 2016 at 7:56 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=76735 >
> >
> > I'm positive. That was the only change I made between runs. I
did it
> > multiple times yesterday and today to convince myself that was the
> reason.
> >
> > Can you think of anything in the the MODE config file that would
force
> > such a dependency?
> >
> > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I
need
> > to run 480 verifications, so I'll never get this done in a
reasonable
> > amount of time. While I may drop some forecast hours if no
solution
> > can be found, a solution would be even better as it seems the
longest
> > step is that PostScript build.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, June 14, 2016 3:38 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
> >
> > Matt,
> >
> > Wow, that is a very odd symptom! I just reran your case twice
with
> > "ps_plot_flag" set to TRUE and FALSE.
> >
> > I compared the output "_obj.txt" files and found them to be
identical.
> >
> > Are you positive that the only configuration file change you made
was
> > in ps_plot_flag? If you're using environment variables in the
config
> > file, please check their values to make sure they are set as you
> intended.
> >
> > So I'm not able to replicate the behavior you describe using the
> > latest
> > met-5.1 bugfix release.
> >
> > Thanks,
> > John
> >
> > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
> > >
> > > Hey John,
> > >
> > > This will sound bizarre, but the only way I can generate
meaningful
> > > numbers in the ".obj.txt" is when I have "ps_plot_flag = TRUE"
in
> > > the MODE config file. When I switch it to "FALSE" I get all
zeroes.
> > >
> > > Can you replicate on your side? Do I *have* to have that flag
on to
> > > force the matching process to even take place? I don't need the
".ps"
> > > output files, just the numbers in ".obj.txt".
> > >
> > > Matt
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Tuesday, June 14, 2016 11:26 AM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > Thanks for sending the WWMCA-Regrid config file info. When I
used
> > > your settings, I was able to replicate your "bad" result. The
> > > WWMCA-North and WWMCA-South grids are actually predefined in the
> > > code and named "wwma_north" and "wwmca_south". So I updated the
> "to_grid"
> > > in your config file to read:
> > > to_grid = "wwmca_north";
> > >
> > > Then I plotted/attached the result. I also attached the plot of
the
> > > forecast data for reference. Notice that the forecast grid is
> > > upside-down and flipped relative to the WWMCA grid. So you will
> > > need to use the "regrid" option when running mode to compare
this
> > > data. If you pass the "fcsts_t005..." file as the forecast and
the
> > > WWMCA data as the observation, my suggestion would be to regrid
to the
> OBS
> > > field.
> > > That way the output will be on the conventional WWMCA North
grid.
> > >
> > > Please give that a shot and take a close look at both the ascii
> > > output from MODE and the PostScript output.
> > >
> > > Hope that helps.
> > >
> > > John
> > >
> > >
> > > On Tue, Jun 14, 2016 at 6:42 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=76735
>
> > > >
> > > > Hi John,
> > > >
> > > > Wow, that WWMCA is way off. Here's how I call it:
> > > >
> > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
${regrid_cfg_file}
> > > > -nh ${obs_nh_met_name} -sh ${obs_sh_met_name} -v 4
> > > >
> > > > I pushed the NH and SH WWMCA files to the FTP site for you
just
> > > > now (should have thought to do that yesterday).
> > > >
> > > > The config file contents:
> > > >
> > > > regrid = {
> > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
> 6367.47
> > 0
> > > > N";
> > > > vld_thresh = 0.5;
> > > > method = NEAREST;
> > > > width = 1;
> > > > }
> > > >
> > > >
> > > >
//////////////////////////////////////////////////////////////////
> > > > //
> > > > //
> > > > //////////
> > > >
> > > > //
> > > > // NetCDF output information
> > > > //
> > > > variable_name = "Cloud_Pct";
> > > > units = "percent";
> > > > long_name = "cloud cover percent";
> > > > level = "SFC";
> > > >
> > > >
> > > >
//////////////////////////////////////////////////////////////////
> > > > //
> > > > //
> > > > //////////
> > > >
> > > > //
> > > > // Maximum pixel age in minutes
> > > > //
> > > > max_minutes = 1440;
> > > >
> > > > I'm guessing I messed up the "to_grid"? I was trying to get
it to
> > > > match the model data of course.
> > > >
> > > > Thanks,
> > > > Matt
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, June 13, 2016 3:50 PM
> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > matthew.sittel.ctr at us.af.mil>
> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > > Output
> > > >
> > > > Matt,
> > > >
> > > > OK, here's what I've found...
> > > >
> > > > (1) wwmca_regrid version 5.1 writes the accumulation interval
> > > > global attribute like this:
> > > > Cloud_Pct:accum_time = "1 hour" ;
> > > >
> > > > The current development version (i.e. for the 5.2 release)
writes
> > > > it like
> > > > this:
> > > > Cloud_Pct:accum_time = "010000" ;
> > > > Cloud_Pct:accum_time_sec = 3600 ;
> > > >
> > > > MET actually doesn't even parse the "accum_time" string.
Instead,
> > > > its looking for "accum_time_sec". Since that is missing, the
> > > > accumulation interval is set to it's default value of bad data
(i.e.
> > > > a value of
> > > -9999).
> > > > We are failing to check for bad data and -9999 is interpreted
as a
> > > > number of second and converted to that weird string "-02-46-
39".
> > > >
> > > > Version 5.2 of wwmca_regrid will store the accumulation
interval
> > > > in the expected way. So it won't have this bad data issue.
> > > >
> > > > However, this is the second time this weird string has popped
up.
> > > > I'll add some logic to check for this and write "000000"
instead
> > > > of
> > > "-02-46-39".
> > > >
> > > > (2) I ran plot_data_plane on the data files you sent and have
> > > > attached the resulting images in PNG format. The GRIB1
forecast
> > > > looks fine but the WWMCA data does not:
> > > >
> > > > /d1/johnhg/MET/MET_development/
> > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > fcsts_t005_2016040100_036.GR1 \
> > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC"; level="L0";'
> > > >
> > > > /d1/johnhg/MET/MET_development/
> > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
> > > > 'name="Cloud_Pct"; level="(*,*)";'
> > > >
> > > > Notice how weird the WWMCA map data looks. I think we should
step
> > > > back and work on the wwmca_regrid output. Can you tell me
what
> > > > commands you used to run that one?
> > > >
> > > > FYI, when I ran MODE on this data, I didn't see all the 0's
you
> > > > were seeing. I got reasonable looking output. But let's
> > > > straighten out wwmca_regrid before moving on to that.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 13, 2016 at 10:31 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=76735 >
> > > > >
> > > > > I just posted the files in 'sittel_data'. This is using the
> > > > > recently recompiled v5.1 executables.
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > > Sent: Monday, June 13, 2016 11:18 AM
> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > > matthew.sittel.ctr at us.af.mil>
> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
> > > > > Output
> > > > >
> > > > > Matt,
> > > > >
> > > > > Yes, that certainly doesn't look like very meaningful output
> > > > > from
> > MODE!
> > > > >
> > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do
the
> > > > > math
> > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > > > curiously, is the value we use for missing data. I strongly
> > > > > suspect that we're missing a check for bad data somewhere.
When
> > > > > the accumulation interval is bad data (-9999), we should
either
> > > > > write out "000000" or "NA". Using "00000" would likely
avoid
> > > > > parsing headaches down the line. But no, I don't think this
has
> > > > > anything to do with the bad object
> > > > output you're getting.
> > > > >
> > > > > Are you able to send me sample files for your MODE run
(fcst,
> > > > > obs, and config file)? I'll run it here, reproduce the
behavior
> > > > > you're seeing, and then try to figure it out. Could you
post it
> > > > > to our anonymous ftp
> > > > site?
> > > > >
> > > > > Being able to replicate the "-02-46-39" will make it easy
for me
> > > > > to fix that one.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF
AFWA
> > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
> > > > > > Queue: met_help
> > > > > > Subject: Confusion over MODE .obj Output
> > > > > > Owner: Nobody
> > > > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > > > Status: new
> > > > > > Ticket <URL:
> > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to figure out if I have a problem with the way
I
> > > > > > have configured MODE to run.
> > > > > >
> > > > > > I am attempting to build cloud objects (based on a
threshold
> > > > > > of cloud cover being 95% or greater) from DCF cloud model
data
> > > > > > and WWMCA ground truth analyses.
> > > > > >
> > > > > > In the example I just ran I have entries in an output .obj
> > > > > > file, one line for each of the 30 forecast objects, then a
> > > > > > line for each of 26 observation objects, and lines for
each of
> > > > > > the 30x26
> > > > > forecast-observation pairs.
> > > > > >
> > > > > > Below are a few lines from the output file.
> > > > > >
> > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
> > OBS_VALID
> > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
FCST_LEV
> > > > > > OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X
CENTROID_Y
> > > > > > CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH AREA
> > > > > > AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X CURVATURE_Y
> > > > > > COMPLEXITY
> > > > > > INTENSITY_10 INTENSITY_25
> > > > > INTENSITY_50
> > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
> > CENTROID_DIST
> > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> > > > > > PERCENTILE_INTENSITY_RATIO
> > INTEREST
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F002 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F003 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O001 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O002 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O003 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > >
> > > > > > What I can't figure out is how MODE apparently diagnosed
30
> > > > > > forecast objects and 26 observation objects, but has
nothing
> > > > > > but zeroes and missing values.
> > > > > >
> > > > > > A couple of parts that might be of concern, or help in
> diagnosing:
> > > > > >
> > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it
is
> > > > > > indicative of the problem.
> > > > > > 2. The centroid lat/lon of each object is always the same.
> > > > > > This is a northern hemisphere product and I believe
> > > > > > (-20.837,55) is a corner point for the WWMCA data. Note
that
> > > > > > the WWMCA observation data are created by WWMCA_REGRID.
> > > > > >
> > > > > > // SIGNED //
> > > > > > Matthew C. Sittel
> > > > > > University Corporation for Atmospheric Research
> > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
matthew.sittel.ctr at us.af.mil
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Wed Jun 15 12:18:06 2016
No problem - I'm happy to send anything I can to help diagnose the
problem.
To clarify a bit, when ps_flag = TRUE, and I need to run wwmca_regrid,
it
takes 2.5 minutes for the wwmca_regrid step and 7:10 minutes for MODE
to run.
When I set it ps_flag = FALSE, MODE ran it ran in 2:23.
".obj.txt" files, appended with the value of ps_flag, are attached.
You'll
note they are much different files!
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, June 15, 2016 12:48 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
Great, thanks.
Sorry to ask for so much data on this, but it would also be helpful
see the
two version of the output "_obj.txt" file. The one generated with
ps_flag =
TRUE and the other one with ps_flag = FALSE.
As for timing information, I'm surprised there is that large of a
discrepancy
between the two. When I run your test case, running with ps_flag =
TRUE takes
4:25 while running with ps_flag = FALSE takes 3:58.
27 seconds is a significant difference, but represents only about a
10%
runtime difference.
You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
What is it
with ps_flag = FALSE?
Thanks,
John
On Wed, Jun 15, 2016 at 11:10 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=76735 >
>
> Yes it's 5.1 with the May 23 patches applied.
>
> Config log attached.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, June 15, 2016 11:39 AM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
> <matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Yes, that is very odd behavior.
>
> Let's clarify out exactly what version of MET you're running. I
know
> it's version 5.1, but what is the date of the latest patches you've
applied?
> Also, didn't I send you updates for wwmca_regrid? Are those also
applied?
>
> Lastly, can you send me the config.log file in your top-level MET
> directory?
> That'll tell me the compilers used and options compiled.
>
> Thanks,
> John
>
> On Wed, Jun 15, 2016 at 7:56 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=76735 >
> >
> > I'm positive. That was the only change I made between runs. I
did
> > it multiple times yesterday and today to convince myself that was
> > the
> reason.
> >
> > Can you think of anything in the the MODE config file that would
> > force such a dependency?
> >
> > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I
need
> > to run 480 verifications, so I'll never get this done in a
> > reasonable amount of time. While I may drop some forecast hours
if
> > no solution can be found, a solution would be even better as it
> > seems the longest step is that PostScript build.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Tuesday, June 14, 2016 3:38 PM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > Output
> >
> > Matt,
> >
> > Wow, that is a very odd symptom! I just reran your case twice
with
> > "ps_plot_flag" set to TRUE and FALSE.
> >
> > I compared the output "_obj.txt" files and found them to be
identical.
> >
> > Are you positive that the only configuration file change you made
> > was in ps_plot_flag? If you're using environment variables in the
> > config file, please check their values to make sure they are set
as
> > you
> intended.
> >
> > So I'm not able to replicate the behavior you describe using the
> > latest
> > met-5.1 bugfix release.
> >
> > Thanks,
> > John
> >
> > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
> > >
> > > Hey John,
> > >
> > > This will sound bizarre, but the only way I can generate
> > > meaningful numbers in the ".obj.txt" is when I have
"ps_plot_flag
> > > = TRUE" in the MODE config file. When I switch it to "FALSE" I
get all
> > > zeroes.
> > >
> > > Can you replicate on your side? Do I *have* to have that flag
on
> > > to force the matching process to even take place? I don't need
the
> > > ".ps"
> > > output files, just the numbers in ".obj.txt".
> > >
> > > Matt
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Tuesday, June 14, 2016 11:26 AM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > Thanks for sending the WWMCA-Regrid config file info. When I
used
> > > your settings, I was able to replicate your "bad" result. The
> > > WWMCA-North and WWMCA-South grids are actually predefined in the
> > > code and named "wwma_north" and "wwmca_south". So I updated the
> "to_grid"
> > > in your config file to read:
> > > to_grid = "wwmca_north";
> > >
> > > Then I plotted/attached the result. I also attached the plot of
> > > the forecast data for reference. Notice that the forecast grid
is
> > > upside-down and flipped relative to the WWMCA grid. So you will
> > > need to use the "regrid" option when running mode to compare
this
> > > data. If you pass the "fcsts_t005..." file as the forecast and
> > > the WWMCA data as the observation, my suggestion would be to
> > > regrid to the
> OBS
> > > field.
> > > That way the output will be on the conventional WWMCA North
grid.
> > >
> > > Please give that a shot and take a close look at both the ascii
> > > output from MODE and the PostScript output.
> > >
> > > Hope that helps.
> > >
> > > John
> > >
> > >
> > > On Tue, Jun 14, 2016 at 6:42 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=76735
>
> > > >
> > > > Hi John,
> > > >
> > > > Wow, that WWMCA is way off. Here's how I call it:
> > > >
> > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
> > > > ${regrid_cfg_file} -nh ${obs_nh_met_name} -sh
${obs_sh_met_name}
> > > > -v 4
> > > >
> > > > I pushed the NH and SH WWMCA files to the FTP site for you
just
> > > > now (should have thought to do that yesterday).
> > > >
> > > > The config file contents:
> > > >
> > > > regrid = {
> > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000 23.813
> 6367.47
> > 0
> > > > N";
> > > > vld_thresh = 0.5;
> > > > method = NEAREST;
> > > > width = 1;
> > > > }
> > > >
> > > >
> > > >
////////////////////////////////////////////////////////////////
> > > > //
> > > > //
> > > > //
> > > > //////////
> > > >
> > > > //
> > > > // NetCDF output information
> > > > //
> > > > variable_name = "Cloud_Pct";
> > > > units = "percent";
> > > > long_name = "cloud cover percent";
> > > > level = "SFC";
> > > >
> > > >
> > > >
////////////////////////////////////////////////////////////////
> > > > //
> > > > //
> > > > //
> > > > //////////
> > > >
> > > > //
> > > > // Maximum pixel age in minutes
> > > > //
> > > > max_minutes = 1440;
> > > >
> > > > I'm guessing I messed up the "to_grid"? I was trying to get
it
> > > > to match the model data of course.
> > > >
> > > > Thanks,
> > > > Matt
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Monday, June 13, 2016 3:50 PM
> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > matthew.sittel.ctr at us.af.mil>
> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > > Output
> > > >
> > > > Matt,
> > > >
> > > > OK, here's what I've found...
> > > >
> > > > (1) wwmca_regrid version 5.1 writes the accumulation interval
> > > > global attribute like this:
> > > > Cloud_Pct:accum_time = "1 hour" ;
> > > >
> > > > The current development version (i.e. for the 5.2 release)
> > > > writes it like
> > > > this:
> > > > Cloud_Pct:accum_time = "010000" ;
> > > > Cloud_Pct:accum_time_sec = 3600 ;
> > > >
> > > > MET actually doesn't even parse the "accum_time" string.
> > > > Instead, its looking for "accum_time_sec". Since that is
> > > > missing, the accumulation interval is set to it's default
value of bad
> > > > data (i.e.
> > > > a value of
> > > -9999).
> > > > We are failing to check for bad data and -9999 is interpreted
as
> > > > a number of second and converted to that weird string "-02-46-
39".
> > > >
> > > > Version 5.2 of wwmca_regrid will store the accumulation
interval
> > > > in the expected way. So it won't have this bad data issue.
> > > >
> > > > However, this is the second time this weird string has popped
up.
> > > > I'll add some logic to check for this and write "000000"
instead
> > > > of
> > > "-02-46-39".
> > > >
> > > > (2) I ran plot_data_plane on the data files you sent and have
> > > > attached the resulting images in PNG format. The GRIB1
forecast
> > > > looks fine but the WWMCA data does not:
> > > >
> > > > /d1/johnhg/MET/MET_development/
> > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > fcsts_t005_2016040100_036.GR1 \
> > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC"; level="L0";'
> > > >
> > > > /d1/johnhg/MET/MET_development/
> > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
> > > > 'name="Cloud_Pct"; level="(*,*)";'
> > > >
> > > > Notice how weird the WWMCA map data looks. I think we should
> > > > step back and work on the wwmca_regrid output. Can you tell
me
> > > > what commands you used to run that one?
> > > >
> > > > FYI, when I ran MODE on this data, I didn't see all the 0's
you
> > > > were seeing. I got reasonable looking output. But let's
> > > > straighten out wwmca_regrid before moving on to that.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 13, 2016 at 10:31 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=76735
> > > > > >
> > > > >
> > > > > I just posted the files in 'sittel_data'. This is using the
> > > > > recently recompiled v5.1 executables.
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > > Sent: Monday, June 13, 2016 11:18 AM
> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > > matthew.sittel.ctr at us.af.mil>
> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
> > > > > Output
> > > > >
> > > > > Matt,
> > > > >
> > > > > Yes, that certainly doesn't look like very meaningful output
> > > > > from
> > MODE!
> > > > >
> > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you do
> > > > > the math
> > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > > > curiously, is the value we use for missing data. I strongly
> > > > > suspect that we're missing a check for bad data somewhere.
> > > > > When the accumulation interval is bad data (-9999), we
should
> > > > > either write out "000000" or "NA". Using "00000" would
likely
> > > > > avoid parsing headaches down the line. But no, I don't
think
> > > > > this has anything to do with the bad object
> > > > output you're getting.
> > > > >
> > > > > Are you able to send me sample files for your MODE run
(fcst,
> > > > > obs, and config file)? I'll run it here, reproduce the
> > > > > behavior you're seeing, and then try to figure it out.
Could
> > > > > you post it to our anonymous ftp
> > > > site?
> > > > >
> > > > > Being able to replicate the "-02-46-39" will make it easy
for
> > > > > me to fix that one.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR USAF
> > > > > AFWA
> > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
> > > > > > Queue: met_help
> > > > > > Subject: Confusion over MODE .obj Output
> > > > > > Owner: Nobody
> > > > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > > > Status: new
> > > > > > Ticket <URL:
> > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to figure out if I have a problem with the way
I
> > > > > > have configured MODE to run.
> > > > > >
> > > > > > I am attempting to build cloud objects (based on a
threshold
> > > > > > of cloud cover being 95% or greater) from DCF cloud model
> > > > > > data and WWMCA ground truth analyses.
> > > > > >
> > > > > > In the example I just ran I have entries in an output .obj
> > > > > > file, one line for each of the 30 forecast objects, then a
> > > > > > line for each of 26 observation objects, and lines for
each
> > > > > > of the 30x26
> > > > > forecast-observation pairs.
> > > > > >
> > > > > > Below are a few lines from the output file.
> > > > > >
> > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
> > OBS_VALID
> > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
> > > > > > FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT CENTROID_X
> > > > > > CENTROID_Y CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH WIDTH
> > > > > > AREA AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X
> > > > > > CURVATURE_Y COMPLEXITY
> > > > > > INTENSITY_10 INTENSITY_25
> > > > > INTENSITY_50
> > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
> > CENTROID_DIST
> > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> > > > > > PERCENTILE_INTENSITY_RATIO
> > INTEREST
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F002 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F003 CF000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O001 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O002 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC O003 CO000 0
0
> > > > > > -20.837 55 0 0 0 0
0
> > > 0
> > > > > > 0 0 0 0 0
> 0
> > > > > > 0 0 0 0
0
> > > > > NA
> > > > > > NA NA NA NA
> > NA
> > > > > > NA NA NA
NA
> > > > > > NA NA
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > > V5.1 DCF 360000 20160402_120000 000000 000000
> > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0 TCDC
> > > > L0
> > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
NA
> > > > NA
> > > > > > NA NA NA NA NA NA
> NA
> > > > > > NA NA NA NA NA
NA
> > > > > > NA NA NA NA NA
> > > > 0
> > > > > > 0 0 0 0
> 0
> > > > > > 0 0 0 0
> > > > > > 0 0
> > > > > >
> > > > > > What I can't figure out is how MODE apparently diagnosed
30
> > > > > > forecast objects and 26 observation objects, but has
nothing
> > > > > > but zeroes and missing values.
> > > > > >
> > > > > > A couple of parts that might be of concern, or help in
> diagnosing:
> > > > > >
> > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it
is
> > > > > > indicative of the problem.
> > > > > > 2. The centroid lat/lon of each object is always the same.
> > > > > > This is a northern hemisphere product and I believe
> > > > > > (-20.837,55) is a corner point for the WWMCA data. Note
> > > > > > that the WWMCA observation data are created by
WWMCA_REGRID.
> > > > > >
> > > > > > // SIGNED //
> > > > > > Matthew C. Sittel
> > > > > > University Corporation for Atmospheric Research
> > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > > > > matthew.sittel.ctr at us.af.mil
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Thu Jun 16 14:17:09 2016
Matt,
Good news. I was finally able to replicate the behavior your seeing.
If
both ps_plot_flag and nc_pairs_flag are set to FALSE, then this
behavior
occurs.
Randy and I inspected the code and found that offending line. We
can't
figure out how that logic made it in there. Thanks for catching it!
In case you're interested, the problem is the "if" statement on line
372 of
the file mode_exec.cc:
370 // Do matching and merging
371
372 if ( engine.conf_info.ps_plot_flag ||
!(engine.conf_info.nc_info.all_false()) ) {
We are only performing matching/merging if that expression is true.
But
ps_plot_flag and nc_pairs_flag don't apply. I suspect we mean to be
checking different flags there.
I need to complete the testing of the fix, and then I'll post an
updated
set of met-5.1 patches.
Thanks,
John
On Wed, Jun 15, 2016 at 12:18 PM, 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=76735 >
>
> No problem - I'm happy to send anything I can to help diagnose the
problem.
>
> To clarify a bit, when ps_flag = TRUE, and I need to run
wwmca_regrid, it
> takes 2.5 minutes for the wwmca_regrid step and 7:10 minutes for
MODE to
> run.
> When I set it ps_flag = FALSE, MODE ran it ran in 2:23.
>
> ".obj.txt" files, appended with the value of ps_flag, are attached.
You'll
> note they are much different files!
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, June 15, 2016 12:48 PM
> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
> <matthew.sittel.ctr at us.af.mil>
> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>
> Matt,
>
> Great, thanks.
>
> Sorry to ask for so much data on this, but it would also be helpful
see the
> two version of the output "_obj.txt" file. The one generated with
ps_flag
> =
> TRUE and the other one with ps_flag = FALSE.
>
> As for timing information, I'm surprised there is that large of a
> discrepancy
> between the two. When I run your test case, running with ps_flag =
TRUE
> takes
> 4:25 while running with ps_flag = FALSE takes 3:58.
> 27 seconds is a significant difference, but represents only about a
10%
> runtime difference.
>
> You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
What is
> it
> with ps_flag = FALSE?
>
> Thanks,
> John
>
> On Wed, Jun 15, 2016 at 11:10 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=76735 >
> >
> > Yes it's 5.1 with the May 23 patches applied.
> >
> > Config log attached.
> >
> > -----Original Message-----
> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > Sent: Wednesday, June 15, 2016 11:39 AM
> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
> > <matthew.sittel.ctr at us.af.mil>
> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
> >
> > Matt,
> >
> > Yes, that is very odd behavior.
> >
> > Let's clarify out exactly what version of MET you're running. I
know
> > it's version 5.1, but what is the date of the latest patches
you've
> applied?
> > Also, didn't I send you updates for wwmca_regrid? Are those also
> applied?
> >
> > Lastly, can you send me the config.log file in your top-level MET
> > directory?
> > That'll tell me the compilers used and options compiled.
> >
> > Thanks,
> > John
> >
> > On Wed, Jun 15, 2016 at 7:56 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=76735 >
> > >
> > > I'm positive. That was the only change I made between runs. I
did
> > > it multiple times yesterday and today to convince myself that
was
> > > the
> > reason.
> > >
> > > Can you think of anything in the the MODE config file that would
> > > force such a dependency?
> > >
> > > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I
need
> > > to run 480 verifications, so I'll never get this done in a
> > > reasonable amount of time. While I may drop some forecast hours
if
> > > no solution can be found, a solution would be even better as it
> > > seems the longest step is that PostScript build.
> > >
> > > -----Original Message-----
> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > Sent: Tuesday, June 14, 2016 3:38 PM
> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > matthew.sittel.ctr at us.af.mil>
> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > Output
> > >
> > > Matt,
> > >
> > > Wow, that is a very odd symptom! I just reran your case twice
with
> > > "ps_plot_flag" set to TRUE and FALSE.
> > >
> > > I compared the output "_obj.txt" files and found them to be
identical.
> > >
> > > Are you positive that the only configuration file change you
made
> > > was in ps_plot_flag? If you're using environment variables in
the
> > > config file, please check their values to make sure they are set
as
> > > you
> > intended.
> > >
> > > So I'm not able to replicate the behavior you describe using the
> > > latest
> > > met-5.1 bugfix release.
> > >
> > > Thanks,
> > > John
> > >
> > > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735
>
> > > >
> > > > Hey John,
> > > >
> > > > This will sound bizarre, but the only way I can generate
> > > > meaningful numbers in the ".obj.txt" is when I have
"ps_plot_flag
> > > > = TRUE" in the MODE config file. When I switch it to "FALSE"
I get
> all
> > > > zeroes.
> > > >
> > > > Can you replicate on your side? Do I *have* to have that flag
on
> > > > to force the matching process to even take place? I don't
need the
> > > > ".ps"
> > > > output files, just the numbers in ".obj.txt".
> > > >
> > > > Matt
> > > >
> > > > -----Original Message-----
> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > Sent: Tuesday, June 14, 2016 11:26 AM
> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > matthew.sittel.ctr at us.af.mil>
> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
> > > > Output
> > > >
> > > > Matt,
> > > >
> > > > Thanks for sending the WWMCA-Regrid config file info. When I
used
> > > > your settings, I was able to replicate your "bad" result. The
> > > > WWMCA-North and WWMCA-South grids are actually predefined in
the
> > > > code and named "wwma_north" and "wwmca_south". So I updated
the
> > "to_grid"
> > > > in your config file to read:
> > > > to_grid = "wwmca_north";
> > > >
> > > > Then I plotted/attached the result. I also attached the plot
of
> > > > the forecast data for reference. Notice that the forecast
grid is
> > > > upside-down and flipped relative to the WWMCA grid. So you
will
> > > > need to use the "regrid" option when running mode to compare
this
> > > > data. If you pass the "fcsts_t005..." file as the forecast
and
> > > > the WWMCA data as the observation, my suggestion would be to
> > > > regrid to the
> > OBS
> > > > field.
> > > > That way the output will be on the conventional WWMCA North
grid.
> > > >
> > > > Please give that a shot and take a close look at both the
ascii
> > > > output from MODE and the PostScript output.
> > > >
> > > > Hope that helps.
> > > >
> > > > John
> > > >
> > > >
> > > > On Tue, Jun 14, 2016 at 6:42 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=76735 >
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Wow, that WWMCA is way off. Here's how I call it:
> > > > >
> > > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
> > > > > ${regrid_cfg_file} -nh ${obs_nh_met_name} -sh
${obs_sh_met_name}
> > > > > -v 4
> > > > >
> > > > > I pushed the NH and SH WWMCA files to the FTP site for you
just
> > > > > now (should have thought to do that yesterday).
> > > > >
> > > > > The config file contents:
> > > > >
> > > > > regrid = {
> > > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000
23.813
> > 6367.47
> > > 0
> > > > > N";
> > > > > vld_thresh = 0.5;
> > > > > method = NEAREST;
> > > > > width = 1;
> > > > > }
> > > > >
> > > > >
> > > > >
////////////////////////////////////////////////////////////////
> > > > > //
> > > > > //
> > > > > //
> > > > > //////////
> > > > >
> > > > > //
> > > > > // NetCDF output information
> > > > > //
> > > > > variable_name = "Cloud_Pct";
> > > > > units = "percent";
> > > > > long_name = "cloud cover percent";
> > > > > level = "SFC";
> > > > >
> > > > >
> > > > >
////////////////////////////////////////////////////////////////
> > > > > //
> > > > > //
> > > > > //
> > > > > //////////
> > > > >
> > > > > //
> > > > > // Maximum pixel age in minutes
> > > > > //
> > > > > max_minutes = 1440;
> > > > >
> > > > > I'm guessing I messed up the "to_grid"? I was trying to get
it
> > > > > to match the model data of course.
> > > > >
> > > > > Thanks,
> > > > > Matt
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > > Sent: Monday, June 13, 2016 3:50 PM
> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > > matthew.sittel.ctr at us.af.mil>
> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
> > > > > Output
> > > > >
> > > > > Matt,
> > > > >
> > > > > OK, here's what I've found...
> > > > >
> > > > > (1) wwmca_regrid version 5.1 writes the accumulation
interval
> > > > > global attribute like this:
> > > > > Cloud_Pct:accum_time = "1 hour" ;
> > > > >
> > > > > The current development version (i.e. for the 5.2 release)
> > > > > writes it like
> > > > > this:
> > > > > Cloud_Pct:accum_time = "010000" ;
> > > > > Cloud_Pct:accum_time_sec = 3600 ;
> > > > >
> > > > > MET actually doesn't even parse the "accum_time" string.
> > > > > Instead, its looking for "accum_time_sec". Since that is
> > > > > missing, the accumulation interval is set to it's default
value of
> bad
> > > > > data (i.e.
> > > > > a value of
> > > > -9999).
> > > > > We are failing to check for bad data and -9999 is
interpreted as
> > > > > a number of second and converted to that weird string "-02-
46-39".
> > > > >
> > > > > Version 5.2 of wwmca_regrid will store the accumulation
interval
> > > > > in the expected way. So it won't have this bad data issue.
> > > > >
> > > > > However, this is the second time this weird string has
popped up.
> > > > > I'll add some logic to check for this and write "000000"
instead
> > > > > of
> > > > "-02-46-39".
> > > > >
> > > > > (2) I ran plot_data_plane on the data files you sent and
have
> > > > > attached the resulting images in PNG format. The GRIB1
forecast
> > > > > looks fine but the WWMCA data does not:
> > > > >
> > > > > /d1/johnhg/MET/MET_development/
> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > > fcsts_t005_2016040100_036.GR1 \
> > > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC";
level="L0";'
> > > > >
> > > > > /d1/johnhg/MET/MET_development/
> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
> > > > > 'name="Cloud_Pct"; level="(*,*)";'
> > > > >
> > > > > Notice how weird the WWMCA map data looks. I think we
should
> > > > > step back and work on the wwmca_regrid output. Can you tell
me
> > > > > what commands you used to run that one?
> > > > >
> > > > > FYI, when I ran MODE on this data, I didn't see all the 0's
you
> > > > > were seeing. I got reasonable looking output. But let's
> > > > > straighten out wwmca_regrid before moving on to that.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jun 13, 2016 at 10:31 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=76735
> > > > > > >
> > > > > >
> > > > > > I just posted the files in 'sittel_data'. This is using
the
> > > > > > recently recompiled v5.1 executables.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> > > > > > Sent: Monday, June 13, 2016 11:18 AM
> > > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
> > > > > > matthew.sittel.ctr at us.af.mil>
> > > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
> > > > > > Output
> > > > > >
> > > > > > Matt,
> > > > > >
> > > > > > Yes, that certainly doesn't look like very meaningful
output
> > > > > > from
> > > MODE!
> > > > > >
> > > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you
do
> > > > > > the math
> > > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
> > > > > > curiously, is the value we use for missing data. I
strongly
> > > > > > suspect that we're missing a check for bad data somewhere.
> > > > > > When the accumulation interval is bad data (-9999), we
should
> > > > > > either write out "000000" or "NA". Using "00000" would
likely
> > > > > > avoid parsing headaches down the line. But no, I don't
think
> > > > > > this has anything to do with the bad object
> > > > > output you're getting.
> > > > > >
> > > > > > Are you able to send me sample files for your MODE run
(fcst,
> > > > > > obs, and config file)? I'll run it here, reproduce the
> > > > > > behavior you're seeing, and then try to figure it out.
Could
> > > > > > you post it to our anonymous ftp
> > > > > site?
> > > > > >
> > > > > > Being able to replicate the "-02-46-39" will make it easy
for
> > > > > > me to fix that one.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR
USAF
> > > > > > AFWA
> > > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
> > > > > >
> > > > > > >
> > > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
> > > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
> > > > > > > Queue: met_help
> > > > > > > Subject: Confusion over MODE .obj Output
> > > > > > > Owner: Nobody
> > > > > > > Requestors: matthew.sittel.ctr at us.af.mil
> > > > > > > Status: new
> > > > > > > Ticket <URL:
> > > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm trying to figure out if I have a problem with the
way I
> > > > > > > have configured MODE to run.
> > > > > > >
> > > > > > > I am attempting to build cloud objects (based on a
threshold
> > > > > > > of cloud cover being 95% or greater) from DCF cloud
model
> > > > > > > data and WWMCA ground truth analyses.
> > > > > > >
> > > > > > > In the example I just ran I have entries in an output
.obj
> > > > > > > file, one line for each of the 30 forecast objects, then
a
> > > > > > > line for each of 26 observation objects, and lines for
each
> > > > > > > of the 30x26
> > > > > > forecast-observation pairs.
> > > > > > >
> > > > > > > Below are a few lines from the output file.
> > > > > > >
> > > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
> > > OBS_VALID
> > > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
> > > > > > > FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT
CENTROID_X
> > > > > > > CENTROID_Y CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH
WIDTH
> > > > > > > AREA AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X
> > > > > > > CURVATURE_Y COMPLEXITY
> > > > > > > INTENSITY_10 INTENSITY_25
> > > > > > INTENSITY_50
> > > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
> > > CENTROID_DIST
> > > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
> > > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
> > > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
> > > > > > > PERCENTILE_INTENSITY_RATIO
> > > INTEREST
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F001 CF000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F002 CF000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F003 CF000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC O001 CO000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC O002 CO000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC O003 CO000 0
> 0
> > > > > > > -20.837 55 0 0 0 0
0
> > > > 0
> > > > > > > 0 0 0 0 0
> > 0
> > > > > > > 0 0 0 0
0
> > > > > > NA
> > > > > > > NA NA NA NA
> > > NA
> > > > > > > NA NA NA
NA
> > > > > > > NA NA
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
> NA
> > > > > NA
> > > > > > > NA NA NA NA NA NA
> > NA
> > > > > > > NA NA NA NA NA
NA
> > > > > > > NA NA NA NA
NA
> > > > > 0
> > > > > > > 0 0 0 0
> > 0
> > > > > > > 0 0 0
0
> > > > > > > 0 0
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
> NA
> > > > > NA
> > > > > > > NA NA NA NA NA NA
> > NA
> > > > > > > NA NA NA NA NA
NA
> > > > > > > NA NA NA NA
NA
> > > > > 0
> > > > > > > 0 0 0 0
> > 0
> > > > > > > 0 0 0
0
> > > > > > > 0 0
> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
> TCDC
> > > > > L0
> > > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
> NA
> > > > > NA
> > > > > > > NA NA NA NA NA NA
> > NA
> > > > > > > NA NA NA NA NA
NA
> > > > > > > NA NA NA NA
NA
> > > > > 0
> > > > > > > 0 0 0 0
> > 0
> > > > > > > 0 0 0
0
> > > > > > > 0 0
> > > > > > >
> > > > > > > What I can't figure out is how MODE apparently diagnosed
30
> > > > > > > forecast objects and 26 observation objects, but has
nothing
> > > > > > > but zeroes and missing values.
> > > > > > >
> > > > > > > A couple of parts that might be of concern, or help in
> > diagnosing:
> > > > > > >
> > > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if it
is
> > > > > > > indicative of the problem.
> > > > > > > 2. The centroid lat/lon of each object is always the
same.
> > > > > > > This is a northern hemisphere product and I believe
> > > > > > > (-20.837,55) is a corner point for the WWMCA data. Note
> > > > > > > that the WWMCA observation data are created by
WWMCA_REGRID.
> > > > > > >
> > > > > > > // SIGNED //
> > > > > > > Matthew C. Sittel
> > > > > > > University Corporation for Atmospheric Research
> > > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
> > > > > > > matthew.sittel.ctr at us.af.mil
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Thu Jun 16 15:49:16 2016
Matt,
I just posted a new patch file for MET version 5.1. Again, thanks for
altering us to this issue!
Here's the link to grab the updated set of patches:
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
FYI, I also pushed the patch file (met-5.1_patches_20160616.tar.gz
<ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_patches_20160616.tar.gz>)
and the full release plus patches (met-5.1_bugfix.20160616.tar.gz
<ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_bugfix.20160616.tar.gz>)
and a screenshot of that webpage (met-5.1_known_issues.png
<ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_known_issues.png>)
to our anonymous ftp site:
ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches
Thanks,
John
On Thu, Jun 16, 2016 at 2:16 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Matt,
>
> Good news. I was finally able to replicate the behavior your
seeing. If
> both ps_plot_flag and nc_pairs_flag are set to FALSE, then this
behavior
> occurs.
>
> Randy and I inspected the code and found that offending line. We
can't
> figure out how that logic made it in there. Thanks for catching it!
>
> In case you're interested, the problem is the "if" statement on line
372
> of the file mode_exec.cc:
> 370 // Do matching and merging
> 371
> 372 if ( engine.conf_info.ps_plot_flag ||
> !(engine.conf_info.nc_info.all_false()) ) {
>
> We are only performing matching/merging if that expression is true.
But
> ps_plot_flag and nc_pairs_flag don't apply. I suspect we mean to be
> checking different flags there.
>
> I need to complete the testing of the fix, and then I'll post an
updated
> set of met-5.1 patches.
>
> Thanks,
> John
>
> On Wed, Jun 15, 2016 at 12:18 PM, 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=76735 >
>>
>> No problem - I'm happy to send anything I can to help diagnose the
>> problem.
>>
>> To clarify a bit, when ps_flag = TRUE, and I need to run
wwmca_regrid, it
>> takes 2.5 minutes for the wwmca_regrid step and 7:10 minutes for
MODE to
>> run.
>> When I set it ps_flag = FALSE, MODE ran it ran in 2:23.
>>
>> ".obj.txt" files, appended with the value of ps_flag, are attached.
>> You'll
>> note they are much different files!
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Wednesday, June 15, 2016 12:48 PM
>> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>> <matthew.sittel.ctr at us.af.mil>
>> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>>
>> Matt,
>>
>> Great, thanks.
>>
>> Sorry to ask for so much data on this, but it would also be helpful
see
>> the
>> two version of the output "_obj.txt" file. The one generated with
>> ps_flag =
>> TRUE and the other one with ps_flag = FALSE.
>>
>> As for timing information, I'm surprised there is that large of a
>> discrepancy
>> between the two. When I run your test case, running with ps_flag =
TRUE
>> takes
>> 4:25 while running with ps_flag = FALSE takes 3:58.
>> 27 seconds is a significant difference, but represents only about a
10%
>> runtime difference.
>>
>> You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
What
>> is it
>> with ps_flag = FALSE?
>>
>> Thanks,
>> John
>>
>> On Wed, Jun 15, 2016 at 11:10 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=76735 >
>> >
>> > Yes it's 5.1 with the May 23 patches applied.
>> >
>> > Config log attached.
>> >
>> > -----Original Message-----
>> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> > Sent: Wednesday, June 15, 2016 11:39 AM
>> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>> > <matthew.sittel.ctr at us.af.mil>
>> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>> >
>> > Matt,
>> >
>> > Yes, that is very odd behavior.
>> >
>> > Let's clarify out exactly what version of MET you're running. I
know
>> > it's version 5.1, but what is the date of the latest patches
you've
>> applied?
>> > Also, didn't I send you updates for wwmca_regrid? Are those also
>> applied?
>> >
>> > Lastly, can you send me the config.log file in your top-level MET
>> > directory?
>> > That'll tell me the compilers used and options compiled.
>> >
>> > Thanks,
>> > John
>> >
>> > On Wed, Jun 15, 2016 at 7:56 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=76735 >
>> > >
>> > > I'm positive. That was the only change I made between runs. I
did
>> > > it multiple times yesterday and today to convince myself that
was
>> > > the
>> > reason.
>> > >
>> > > Can you think of anything in the the MODE config file that
would
>> > > force such a dependency?
>> > >
>> > > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and I
need
>> > > to run 480 verifications, so I'll never get this done in a
>> > > reasonable amount of time. While I may drop some forecast
hours if
>> > > no solution can be found, a solution would be even better as it
>> > > seems the longest step is that PostScript build.
>> > >
>> > > -----Original Message-----
>> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> > > Sent: Tuesday, June 14, 2016 3:38 PM
>> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>> > > matthew.sittel.ctr at us.af.mil>
>> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
>> > > Output
>> > >
>> > > Matt,
>> > >
>> > > Wow, that is a very odd symptom! I just reran your case twice
with
>> > > "ps_plot_flag" set to TRUE and FALSE.
>> > >
>> > > I compared the output "_obj.txt" files and found them to be
identical.
>> > >
>> > > Are you positive that the only configuration file change you
made
>> > > was in ps_plot_flag? If you're using environment variables in
the
>> > > config file, please check their values to make sure they are
set as
>> > > you
>> > intended.
>> > >
>> > > So I'm not able to replicate the behavior you describe using
the
>> > > latest
>> > > met-5.1 bugfix release.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735
>
>> > > >
>> > > > Hey John,
>> > > >
>> > > > This will sound bizarre, but the only way I can generate
>> > > > meaningful numbers in the ".obj.txt" is when I have
"ps_plot_flag
>> > > > = TRUE" in the MODE config file. When I switch it to "FALSE"
I get
>> all
>> > > > zeroes.
>> > > >
>> > > > Can you replicate on your side? Do I *have* to have that
flag on
>> > > > to force the matching process to even take place? I don't
need the
>> > > > ".ps"
>> > > > output files, just the numbers in ".obj.txt".
>> > > >
>> > > > Matt
>> > > >
>> > > > -----Original Message-----
>> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> > > > Sent: Tuesday, June 14, 2016 11:26 AM
>> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>> > > > matthew.sittel.ctr at us.af.mil>
>> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>> > > > Output
>> > > >
>> > > > Matt,
>> > > >
>> > > > Thanks for sending the WWMCA-Regrid config file info. When I
used
>> > > > your settings, I was able to replicate your "bad" result.
The
>> > > > WWMCA-North and WWMCA-South grids are actually predefined in
the
>> > > > code and named "wwma_north" and "wwmca_south". So I updated
the
>> > "to_grid"
>> > > > in your config file to read:
>> > > > to_grid = "wwmca_north";
>> > > >
>> > > > Then I plotted/attached the result. I also attached the plot
of
>> > > > the forecast data for reference. Notice that the forecast
grid is
>> > > > upside-down and flipped relative to the WWMCA grid. So you
will
>> > > > need to use the "regrid" option when running mode to compare
this
>> > > > data. If you pass the "fcsts_t005..." file as the forecast
and
>> > > > the WWMCA data as the observation, my suggestion would be to
>> > > > regrid to the
>> > OBS
>> > > > field.
>> > > > That way the output will be on the conventional WWMCA North
grid.
>> > > >
>> > > > Please give that a shot and take a close look at both the
ascii
>> > > > output from MODE and the PostScript output.
>> > > >
>> > > > Hope that helps.
>> > > >
>> > > > John
>> > > >
>> > > >
>> > > > On Tue, Jun 14, 2016 at 6:42 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=76735 >
>> > > > >
>> > > > > Hi John,
>> > > > >
>> > > > > Wow, that WWMCA is way off. Here's how I call it:
>> > > > >
>> > > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
>> > > > > ${regrid_cfg_file} -nh ${obs_nh_met_name} -sh
${obs_sh_met_name}
>> > > > > -v 4
>> > > > >
>> > > > > I pushed the NH and SH WWMCA files to the FTP site for you
just
>> > > > > now (should have thought to do that yesterday).
>> > > > >
>> > > > > The config file contents:
>> > > > >
>> > > > > regrid = {
>> > > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000
23.813
>> > 6367.47
>> > > 0
>> > > > > N";
>> > > > > vld_thresh = 0.5;
>> > > > > method = NEAREST;
>> > > > > width = 1;
>> > > > > }
>> > > > >
>> > > > >
>> > > > >
////////////////////////////////////////////////////////////////
>> > > > > //
>> > > > > //
>> > > > > //
>> > > > > //////////
>> > > > >
>> > > > > //
>> > > > > // NetCDF output information
>> > > > > //
>> > > > > variable_name = "Cloud_Pct";
>> > > > > units = "percent";
>> > > > > long_name = "cloud cover percent";
>> > > > > level = "SFC";
>> > > > >
>> > > > >
>> > > > >
////////////////////////////////////////////////////////////////
>> > > > > //
>> > > > > //
>> > > > > //
>> > > > > //////////
>> > > > >
>> > > > > //
>> > > > > // Maximum pixel age in minutes
>> > > > > //
>> > > > > max_minutes = 1440;
>> > > > >
>> > > > > I'm guessing I messed up the "to_grid"? I was trying to
get it
>> > > > > to match the model data of course.
>> > > > >
>> > > > > Thanks,
>> > > > > Matt
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> > > > > Sent: Monday, June 13, 2016 3:50 PM
>> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>> > > > > matthew.sittel.ctr at us.af.mil>
>> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>> > > > > Output
>> > > > >
>> > > > > Matt,
>> > > > >
>> > > > > OK, here's what I've found...
>> > > > >
>> > > > > (1) wwmca_regrid version 5.1 writes the accumulation
interval
>> > > > > global attribute like this:
>> > > > > Cloud_Pct:accum_time = "1 hour" ;
>> > > > >
>> > > > > The current development version (i.e. for the 5.2 release)
>> > > > > writes it like
>> > > > > this:
>> > > > > Cloud_Pct:accum_time = "010000" ;
>> > > > > Cloud_Pct:accum_time_sec = 3600 ;
>> > > > >
>> > > > > MET actually doesn't even parse the "accum_time" string.
>> > > > > Instead, its looking for "accum_time_sec". Since that is
>> > > > > missing, the accumulation interval is set to it's default
value
>> of bad
>> > > > > data (i.e.
>> > > > > a value of
>> > > > -9999).
>> > > > > We are failing to check for bad data and -9999 is
interpreted as
>> > > > > a number of second and converted to that weird string "-02-
46-39".
>> > > > >
>> > > > > Version 5.2 of wwmca_regrid will store the accumulation
interval
>> > > > > in the expected way. So it won't have this bad data issue.
>> > > > >
>> > > > > However, this is the second time this weird string has
popped up.
>> > > > > I'll add some logic to check for this and write "000000"
instead
>> > > > > of
>> > > > "-02-46-39".
>> > > > >
>> > > > > (2) I ran plot_data_plane on the data files you sent and
have
>> > > > > attached the resulting images in PNG format. The GRIB1
forecast
>> > > > > looks fine but the WWMCA data does not:
>> > > > >
>> > > > > /d1/johnhg/MET/MET_development/
>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>> > > > > fcsts_t005_2016040100_036.GR1 \
>> > > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC";
level="L0";'
>> > > > >
>> > > > > /d1/johnhg/MET/MET_development/
>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
>> > > > > 'name="Cloud_Pct"; level="(*,*)";'
>> > > > >
>> > > > > Notice how weird the WWMCA map data looks. I think we
should
>> > > > > step back and work on the wwmca_regrid output. Can you
tell me
>> > > > > what commands you used to run that one?
>> > > > >
>> > > > > FYI, when I ran MODE on this data, I didn't see all the 0's
you
>> > > > > were seeing. I got reasonable looking output. But let's
>> > > > > straighten out wwmca_regrid before moving on to that.
>> > > > >
>> > > > > Thanks,
>> > > > > John
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Mon, Jun 13, 2016 at 10:31 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=76735
>> > > > > > >
>> > > > > >
>> > > > > > I just posted the files in 'sittel_data'. This is using
the
>> > > > > > recently recompiled v5.1 executables.
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: John Halley Gotway via RT
[mailto:met_help at ucar.edu]
>> > > > > > Sent: Monday, June 13, 2016 11:18 AM
>> > > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>> > > > > > matthew.sittel.ctr at us.af.mil>
>> > > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>> > > > > > Output
>> > > > > >
>> > > > > > Matt,
>> > > > > >
>> > > > > > Yes, that certainly doesn't look like very meaningful
output
>> > > > > > from
>> > > MODE!
>> > > > > >
>> > > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you
do
>> > > > > > the math
>> > > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
>> > > > > > curiously, is the value we use for missing data. I
strongly
>> > > > > > suspect that we're missing a check for bad data
somewhere.
>> > > > > > When the accumulation interval is bad data (-9999), we
should
>> > > > > > either write out "000000" or "NA". Using "00000" would
likely
>> > > > > > avoid parsing headaches down the line. But no, I don't
think
>> > > > > > this has anything to do with the bad object
>> > > > > output you're getting.
>> > > > > >
>> > > > > > Are you able to send me sample files for your MODE run
(fcst,
>> > > > > > obs, and config file)? I'll run it here, reproduce the
>> > > > > > behavior you're seeing, and then try to figure it out.
Could
>> > > > > > you post it to our anonymous ftp
>> > > > > site?
>> > > > > >
>> > > > > > Being able to replicate the "-02-46-39" will make it easy
for
>> > > > > > me to fix that one.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > John
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR
USAF
>> > > > > > AFWA
>> > > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
>> > > > > >
>> > > > > > >
>> > > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted upon.
>> > > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
>> > > > > > > Queue: met_help
>> > > > > > > Subject: Confusion over MODE .obj Output
>> > > > > > > Owner: Nobody
>> > > > > > > Requestors: matthew.sittel.ctr at us.af.mil
>> > > > > > > Status: new
>> > > > > > > Ticket <URL:
>> > > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I'm trying to figure out if I have a problem with the
way I
>> > > > > > > have configured MODE to run.
>> > > > > > >
>> > > > > > > I am attempting to build cloud objects (based on a
threshold
>> > > > > > > of cloud cover being 95% or greater) from DCF cloud
model
>> > > > > > > data and WWMCA ground truth analyses.
>> > > > > > >
>> > > > > > > In the example I just ran I have entries in an output
.obj
>> > > > > > > file, one line for each of the 30 forecast objects,
then a
>> > > > > > > line for each of 26 observation objects, and lines for
each
>> > > > > > > of the 30x26
>> > > > > > forecast-observation pairs.
>> > > > > > >
>> > > > > > > Below are a few lines from the output file.
>> > > > > > >
>> > > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
>> > > OBS_VALID
>> > > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
>> > > > > > > FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT
CENTROID_X
>> > > > > > > CENTROID_Y CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH
WIDTH
>> > > > > > > AREA AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X
>> > > > > > > CURVATURE_Y COMPLEXITY
>> > > > > > > INTENSITY_10 INTENSITY_25
>> > > > > > INTENSITY_50
>> > > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
>> > > CENTROID_DIST
>> > > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
>> > > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
>> > > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
>> > > > > > > PERCENTILE_INTENSITY_RATIO
>> > > INTEREST
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F001 CF000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F002 CF000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F003 CF000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC O001 CO000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC O002 CO000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC O003 CO000 0
>> 0
>> > > > > > > -20.837 55 0 0 0 0
0
>> > > > 0
>> > > > > > > 0 0 0 0 0
>> > 0
>> > > > > > > 0 0 0 0
0
>> > > > > > NA
>> > > > > > > NA NA NA NA
>> > > NA
>> > > > > > > NA NA NA
NA
>> > > > > > > NA NA
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
>> NA
>> > > > > NA
>> > > > > > > NA NA NA NA NA NA
>> > NA
>> > > > > > > NA NA NA NA NA
>> NA
>> > > > > > > NA NA NA NA
NA
>> > > > > 0
>> > > > > > > 0 0 0 0
>> > 0
>> > > > > > > 0 0 0
0
>> > > > > > > 0 0
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
>> NA
>> > > > > NA
>> > > > > > > NA NA NA NA NA NA
>> > NA
>> > > > > > > NA NA NA NA NA
>> NA
>> > > > > > > NA NA NA NA
NA
>> > > > > 0
>> > > > > > > 0 0 0 0
>> > 0
>> > > > > > > 0 0 0
0
>> > > > > > > 0 0
>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>> TCDC
>> > > > > L0
>> > > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
>> NA
>> > > > > NA
>> > > > > > > NA NA NA NA NA NA
>> > NA
>> > > > > > > NA NA NA NA NA
>> NA
>> > > > > > > NA NA NA NA
NA
>> > > > > 0
>> > > > > > > 0 0 0 0
>> > 0
>> > > > > > > 0 0 0
0
>> > > > > > > 0 0
>> > > > > > >
>> > > > > > > What I can't figure out is how MODE apparently
diagnosed 30
>> > > > > > > forecast objects and 26 observation objects, but has
nothing
>> > > > > > > but zeroes and missing values.
>> > > > > > >
>> > > > > > > A couple of parts that might be of concern, or help in
>> > diagnosing:
>> > > > > > >
>> > > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if
it is
>> > > > > > > indicative of the problem.
>> > > > > > > 2. The centroid lat/lon of each object is always the
same.
>> > > > > > > This is a northern hemisphere product and I believe
>> > > > > > > (-20.837,55) is a corner point for the WWMCA data.
Note
>> > > > > > > that the WWMCA observation data are created by
WWMCA_REGRID.
>> > > > > > >
>> > > > > > > // SIGNED //
>> > > > > > > Matthew C. Sittel
>> > > > > > > University Corporation for Atmospheric Research
>> > > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
>> > > > > > > matthew.sittel.ctr at us.af.mil
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>
------------------------------------------------
Subject: Confusion over MODE .obj Output
From: John Halley Gotway
Time: Thu Jun 16 16:51:25 2016
Matt,
I cc'ed you on an email to Bob. I just updated the patches to include
both
the MODE fix and the BSS fix.
If you've already grabbed the patch file, please grab it again.
Again, sorry for these issues!
Thanks,
John
On Thu, Jun 16, 2016 at 3:48 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Matt,
>
> I just posted a new patch file for MET version 5.1. Again, thanks
for
> altering us to this issue!
>
> Here's the link to grab the updated set of patches:
>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.php
>
> FYI, I also pushed the patch file (met-5.1_patches_20160616.tar.gz
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_patches_20160616.tar.gz>)
> and the full release plus patches (met-5.1_bugfix.20160616.tar.gz
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_bugfix.20160616.tar.gz>)
> and a screenshot of that webpage (met-5.1_known_issues.png
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1_known_issues.png>)
> to our anonymous ftp site:
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches
>
> Thanks,
> John
>
>
> On Thu, Jun 16, 2016 at 2:16 PM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
>
>> Matt,
>>
>> Good news. I was finally able to replicate the behavior your
seeing. If
>> both ps_plot_flag and nc_pairs_flag are set to FALSE, then this
behavior
>> occurs.
>>
>> Randy and I inspected the code and found that offending line. We
can't
>> figure out how that logic made it in there. Thanks for catching
it!
>>
>> In case you're interested, the problem is the "if" statement on
line 372
>> of the file mode_exec.cc:
>> 370 // Do matching and merging
>> 371
>> 372 if ( engine.conf_info.ps_plot_flag ||
>> !(engine.conf_info.nc_info.all_false()) ) {
>>
>> We are only performing matching/merging if that expression is true.
But
>> ps_plot_flag and nc_pairs_flag don't apply. I suspect we mean to
be
>> checking different flags there.
>>
>> I need to complete the testing of the fix, and then I'll post an
updated
>> set of met-5.1 patches.
>>
>> Thanks,
>> John
>>
>> On Wed, Jun 15, 2016 at 12:18 PM, 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=76735 >
>>>
>>> No problem - I'm happy to send anything I can to help diagnose the
>>> problem.
>>>
>>> To clarify a bit, when ps_flag = TRUE, and I need to run
wwmca_regrid, it
>>> takes 2.5 minutes for the wwmca_regrid step and 7:10 minutes for
MODE to
>>> run.
>>> When I set it ps_flag = FALSE, MODE ran it ran in 2:23.
>>>
>>> ".obj.txt" files, appended with the value of ps_flag, are
attached.
>>> You'll
>>> note they are much different files!
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Wednesday, June 15, 2016 12:48 PM
>>> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>>> <matthew.sittel.ctr at us.af.mil>
>>> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>>>
>>> Matt,
>>>
>>> Great, thanks.
>>>
>>> Sorry to ask for so much data on this, but it would also be
helpful see
>>> the
>>> two version of the output "_obj.txt" file. The one generated with
>>> ps_flag =
>>> TRUE and the other one with ps_flag = FALSE.
>>>
>>> As for timing information, I'm surprised there is that large of a
>>> discrepancy
>>> between the two. When I run your test case, running with ps_flag
= TRUE
>>> takes
>>> 4:25 while running with ps_flag = FALSE takes 3:58.
>>> 27 seconds is a significant difference, but represents only about
a 10%
>>> runtime difference.
>>>
>>> You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
What
>>> is it
>>> with ps_flag = FALSE?
>>>
>>> Thanks,
>>> John
>>>
>>> On Wed, Jun 15, 2016 at 11:10 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=76735 >
>>> >
>>> > Yes it's 5.1 with the May 23 patches applied.
>>> >
>>> > Config log attached.
>>> >
>>> > -----Original Message-----
>>> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > Sent: Wednesday, June 15, 2016 11:39 AM
>>> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>>> > <matthew.sittel.ctr at us.af.mil>
>>> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
Output
>>> >
>>> > Matt,
>>> >
>>> > Yes, that is very odd behavior.
>>> >
>>> > Let's clarify out exactly what version of MET you're running. I
know
>>> > it's version 5.1, but what is the date of the latest patches
you've
>>> applied?
>>> > Also, didn't I send you updates for wwmca_regrid? Are those
also
>>> applied?
>>> >
>>> > Lastly, can you send me the config.log file in your top-level
MET
>>> > directory?
>>> > That'll tell me the compilers used and options compiled.
>>> >
>>> > Thanks,
>>> > John
>>> >
>>> > On Wed, Jun 15, 2016 at 7:56 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=76735
>
>>> > >
>>> > > I'm positive. That was the only change I made between runs.
I did
>>> > > it multiple times yesterday and today to convince myself that
was
>>> > > the
>>> > reason.
>>> > >
>>> > > Can you think of anything in the the MODE config file that
would
>>> > > force such a dependency?
>>> > >
>>> > > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and
I need
>>> > > to run 480 verifications, so I'll never get this done in a
>>> > > reasonable amount of time. While I may drop some forecast
hours if
>>> > > no solution can be found, a solution would be even better as
it
>>> > > seems the longest step is that PostScript build.
>>> > >
>>> > > -----Original Message-----
>>> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > Sent: Tuesday, June 14, 2016 3:38 PM
>>> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > matthew.sittel.ctr at us.af.mil>
>>> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
>>> > > Output
>>> > >
>>> > > Matt,
>>> > >
>>> > > Wow, that is a very odd symptom! I just reran your case twice
with
>>> > > "ps_plot_flag" set to TRUE and FALSE.
>>> > >
>>> > > I compared the output "_obj.txt" files and found them to be
>>> identical.
>>> > >
>>> > > Are you positive that the only configuration file change you
made
>>> > > was in ps_plot_flag? If you're using environment variables in
the
>>> > > config file, please check their values to make sure they are
set as
>>> > > you
>>> > intended.
>>> > >
>>> > > So I'm not able to replicate the behavior you describe using
the
>>> > > latest
>>> > > met-5.1 bugfix release.
>>> > >
>>> > > Thanks,
>>> > > John
>>> > >
>>> > > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735 >
>>> > > >
>>> > > > Hey John,
>>> > > >
>>> > > > This will sound bizarre, but the only way I can generate
>>> > > > meaningful numbers in the ".obj.txt" is when I have
"ps_plot_flag
>>> > > > = TRUE" in the MODE config file. When I switch it to
"FALSE" I
>>> get all
>>> > > > zeroes.
>>> > > >
>>> > > > Can you replicate on your side? Do I *have* to have that
flag on
>>> > > > to force the matching process to even take place? I don't
need the
>>> > > > ".ps"
>>> > > > output files, just the numbers in ".obj.txt".
>>> > > >
>>> > > > Matt
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > > Sent: Tuesday, June 14, 2016 11:26 AM
>>> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > matthew.sittel.ctr at us.af.mil>
>>> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>>> > > > Output
>>> > > >
>>> > > > Matt,
>>> > > >
>>> > > > Thanks for sending the WWMCA-Regrid config file info. When
I used
>>> > > > your settings, I was able to replicate your "bad" result.
The
>>> > > > WWMCA-North and WWMCA-South grids are actually predefined in
the
>>> > > > code and named "wwma_north" and "wwmca_south". So I updated
the
>>> > "to_grid"
>>> > > > in your config file to read:
>>> > > > to_grid = "wwmca_north";
>>> > > >
>>> > > > Then I plotted/attached the result. I also attached the
plot of
>>> > > > the forecast data for reference. Notice that the forecast
grid is
>>> > > > upside-down and flipped relative to the WWMCA grid. So you
will
>>> > > > need to use the "regrid" option when running mode to compare
this
>>> > > > data. If you pass the "fcsts_t005..." file as the forecast
and
>>> > > > the WWMCA data as the observation, my suggestion would be to
>>> > > > regrid to the
>>> > OBS
>>> > > > field.
>>> > > > That way the output will be on the conventional WWMCA North
grid.
>>> > > >
>>> > > > Please give that a shot and take a close look at both the
ascii
>>> > > > output from MODE and the PostScript output.
>>> > > >
>>> > > > Hope that helps.
>>> > > >
>>> > > > John
>>> > > >
>>> > > >
>>> > > > On Tue, Jun 14, 2016 at 6:42 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=76735 >
>>> > > > >
>>> > > > > Hi John,
>>> > > > >
>>> > > > > Wow, that WWMCA is way off. Here's how I call it:
>>> > > > >
>>> > > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
>>> > > > > ${regrid_cfg_file} -nh ${obs_nh_met_name} -sh
${obs_sh_met_name}
>>> > > > > -v 4
>>> > > > >
>>> > > > > I pushed the NH and SH WWMCA files to the FTP site for you
just
>>> > > > > now (should have thought to do that yesterday).
>>> > > > >
>>> > > > > The config file contents:
>>> > > > >
>>> > > > > regrid = {
>>> > > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000
23.813
>>> > 6367.47
>>> > > 0
>>> > > > > N";
>>> > > > > vld_thresh = 0.5;
>>> > > > > method = NEAREST;
>>> > > > > width = 1;
>>> > > > > }
>>> > > > >
>>> > > > >
>>> > > > >
////////////////////////////////////////////////////////////////
>>> > > > > //
>>> > > > > //
>>> > > > > //
>>> > > > > //////////
>>> > > > >
>>> > > > > //
>>> > > > > // NetCDF output information
>>> > > > > //
>>> > > > > variable_name = "Cloud_Pct";
>>> > > > > units = "percent";
>>> > > > > long_name = "cloud cover percent";
>>> > > > > level = "SFC";
>>> > > > >
>>> > > > >
>>> > > > >
////////////////////////////////////////////////////////////////
>>> > > > > //
>>> > > > > //
>>> > > > > //
>>> > > > > //////////
>>> > > > >
>>> > > > > //
>>> > > > > // Maximum pixel age in minutes
>>> > > > > //
>>> > > > > max_minutes = 1440;
>>> > > > >
>>> > > > > I'm guessing I messed up the "to_grid"? I was trying to
get it
>>> > > > > to match the model data of course.
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Matt
>>> > > > >
>>> > > > > -----Original Message-----
>>> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > > > Sent: Monday, June 13, 2016 3:50 PM
>>> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > > matthew.sittel.ctr at us.af.mil>
>>> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>>> > > > > Output
>>> > > > >
>>> > > > > Matt,
>>> > > > >
>>> > > > > OK, here's what I've found...
>>> > > > >
>>> > > > > (1) wwmca_regrid version 5.1 writes the accumulation
interval
>>> > > > > global attribute like this:
>>> > > > > Cloud_Pct:accum_time = "1 hour" ;
>>> > > > >
>>> > > > > The current development version (i.e. for the 5.2 release)
>>> > > > > writes it like
>>> > > > > this:
>>> > > > > Cloud_Pct:accum_time = "010000" ;
>>> > > > > Cloud_Pct:accum_time_sec = 3600 ;
>>> > > > >
>>> > > > > MET actually doesn't even parse the "accum_time" string.
>>> > > > > Instead, its looking for "accum_time_sec". Since that is
>>> > > > > missing, the accumulation interval is set to it's default
value
>>> of bad
>>> > > > > data (i.e.
>>> > > > > a value of
>>> > > > -9999).
>>> > > > > We are failing to check for bad data and -9999 is
interpreted as
>>> > > > > a number of second and converted to that weird string
>>> "-02-46-39".
>>> > > > >
>>> > > > > Version 5.2 of wwmca_regrid will store the accumulation
interval
>>> > > > > in the expected way. So it won't have this bad data
issue.
>>> > > > >
>>> > > > > However, this is the second time this weird string has
popped up.
>>> > > > > I'll add some logic to check for this and write "000000"
instead
>>> > > > > of
>>> > > > "-02-46-39".
>>> > > > >
>>> > > > > (2) I ran plot_data_plane on the data files you sent and
have
>>> > > > > attached the resulting images in PNG format. The GRIB1
forecast
>>> > > > > looks fine but the WWMCA data does not:
>>> > > > >
>>> > > > > /d1/johnhg/MET/MET_development/
>>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>>> > > > > fcsts_t005_2016040100_036.GR1 \
>>> > > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC";
level="L0";'
>>> > > > >
>>> > > > > /d1/johnhg/MET/MET_development/
>>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
>>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
>>> > > > > 'name="Cloud_Pct"; level="(*,*)";'
>>> > > > >
>>> > > > > Notice how weird the WWMCA map data looks. I think we
should
>>> > > > > step back and work on the wwmca_regrid output. Can you
tell me
>>> > > > > what commands you used to run that one?
>>> > > > >
>>> > > > > FYI, when I ran MODE on this data, I didn't see all the
0's you
>>> > > > > were seeing. I got reasonable looking output. But let's
>>> > > > > straighten out wwmca_regrid before moving on to that.
>>> > > > >
>>> > > > > Thanks,
>>> > > > > John
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Mon, Jun 13, 2016 at 10:31 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=76735
>>> > > > > > >
>>> > > > > >
>>> > > > > > I just posted the files in 'sittel_data'. This is using
the
>>> > > > > > recently recompiled v5.1 executables.
>>> > > > > >
>>> > > > > > -----Original Message-----
>>> > > > > > From: John Halley Gotway via RT
[mailto:met_help at ucar.edu]
>>> > > > > > Sent: Monday, June 13, 2016 11:18 AM
>>> > > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > > > matthew.sittel.ctr at us.af.mil>
>>> > > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over
MODE .obj
>>> > > > > > Output
>>> > > > > >
>>> > > > > > Matt,
>>> > > > > >
>>> > > > > > Yes, that certainly doesn't look like very meaningful
output
>>> > > > > > from
>>> > > MODE!
>>> > > > > >
>>> > > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you
do
>>> > > > > > the math
>>> > > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
>>> > > > > > curiously, is the value we use for missing data. I
strongly
>>> > > > > > suspect that we're missing a check for bad data
somewhere.
>>> > > > > > When the accumulation interval is bad data (-9999), we
should
>>> > > > > > either write out "000000" or "NA". Using "00000" would
likely
>>> > > > > > avoid parsing headaches down the line. But no, I don't
think
>>> > > > > > this has anything to do with the bad object
>>> > > > > output you're getting.
>>> > > > > >
>>> > > > > > Are you able to send me sample files for your MODE run
(fcst,
>>> > > > > > obs, and config file)? I'll run it here, reproduce the
>>> > > > > > behavior you're seeing, and then try to figure it out.
Could
>>> > > > > > you post it to our anonymous ftp
>>> > > > > site?
>>> > > > > >
>>> > > > > > Being able to replicate the "-02-46-39" will make it
easy for
>>> > > > > > me to fix that one.
>>> > > > > >
>>> > > > > > Thanks,
>>> > > > > > John
>>> > > > > >
>>> > > > > >
>>> > > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR
USAF
>>> > > > > > AFWA
>>> > > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
>>> > > > > >
>>> > > > > > >
>>> > > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted
upon.
>>> > > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
>>> > > > > > > Queue: met_help
>>> > > > > > > Subject: Confusion over MODE .obj Output
>>> > > > > > > Owner: Nobody
>>> > > > > > > Requestors: matthew.sittel.ctr at us.af.mil
>>> > > > > > > Status: new
>>> > > > > > > Ticket <URL:
>>> > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > Hi,
>>> > > > > > >
>>> > > > > > > I'm trying to figure out if I have a problem with the
way I
>>> > > > > > > have configured MODE to run.
>>> > > > > > >
>>> > > > > > > I am attempting to build cloud objects (based on a
threshold
>>> > > > > > > of cloud cover being 95% or greater) from DCF cloud
model
>>> > > > > > > data and WWMCA ground truth analyses.
>>> > > > > > >
>>> > > > > > > In the example I just ran I have entries in an output
.obj
>>> > > > > > > file, one line for each of the 30 forecast objects,
then a
>>> > > > > > > line for each of 26 observation objects, and lines for
each
>>> > > > > > > of the 30x26
>>> > > > > > forecast-observation pairs.
>>> > > > > > >
>>> > > > > > > Below are a few lines from the output file.
>>> > > > > > >
>>> > > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
>>> > > OBS_VALID
>>> > > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
>>> > > > > > > FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT
CENTROID_X
>>> > > > > > > CENTROID_Y CENTROID_LAT CENTROID_LON AXIS_ANG LENGTH
WIDTH
>>> > > > > > > AREA AREA_FILTER AREA_THRESH CURVATURE CURVATURE_X
>>> > > > > > > CURVATURE_Y COMPLEXITY
>>> > > > > > > INTENSITY_10 INTENSITY_25
>>> > > > > > INTENSITY_50
>>> > > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
>>> > > CENTROID_DIST
>>> > > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
>>> > > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
>>> > > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
>>> > > > > > > PERCENTILE_INTENSITY_RATIO
>>> > > INTEREST
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F002 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F003 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O001 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O002 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O003 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > >
>>> > > > > > > What I can't figure out is how MODE apparently
diagnosed 30
>>> > > > > > > forecast objects and 26 observation objects, but has
nothing
>>> > > > > > > but zeroes and missing values.
>>> > > > > > >
>>> > > > > > > A couple of parts that might be of concern, or help in
>>> > diagnosing:
>>> > > > > > >
>>> > > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if
it is
>>> > > > > > > indicative of the problem.
>>> > > > > > > 2. The centroid lat/lon of each object is always the
same.
>>> > > > > > > This is a northern hemisphere product and I believe
>>> > > > > > > (-20.837,55) is a corner point for the WWMCA data.
Note
>>> > > > > > > that the WWMCA observation data are created by
WWMCA_REGRID.
>>> > > > > > >
>>> > > > > > > // SIGNED //
>>> > > > > > > Matthew C. Sittel
>>> > > > > > > University Corporation for Atmospheric Research
>>> > > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
>>> > > > > > > matthew.sittel.ctr at us.af.mil
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
From: SITTEL, MATTHEW C CTR USAF AFWA 16 WS/WXN
Time: Fri Jun 17 07:02:15 2016
Thanks John - I tested the "TRUE/FALSE" fix and it works.
Mistakes happen; don't worry about it. I'm happy to help test. I
think this my first "patch worthy" find all these years!
I appreciate your (and Randy's) hard work to resolve this issue so
quickly.
Matt
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, June 16, 2016 5:51 PM
To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
<matthew.sittel.ctr at us.af.mil>
Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj Output
Matt,
I cc'ed you on an email to Bob. I just updated the patches to include
both the MODE fix and the BSS fix.
If you've already grabbed the patch file, please grab it again.
Again, sorry for these issues!
Thanks,
John
On Thu, Jun 16, 2016 at 3:48 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Matt,
>
> I just posted a new patch file for MET version 5.1. Again, thanks
for
> altering us to this issue!
>
> Here's the link to grab the updated set of patches:
>
>
http://www.dtcenter.org/met/users/support/known_issues/METv5.1/index.p
> hp
>
> FYI, I also pushed the patch file (met-5.1_patches_20160616.tar.gz
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1
> _patches_20160616.tar.gz>) and the full release plus patches
> (met-5.1_bugfix.20160616.tar.gz
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1
> _bugfix.20160616.tar.gz>) and a screenshot of that webpage
> (met-5.1_known_issues.png
> <ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches/met-
5.1
> _known_issues.png>)
> to our anonymous ftp site:
>
> ftp://ftp.rap.ucar.edu/incoming/irap/met_help/met-5.1_patches
>
> Thanks,
> John
>
>
> On Thu, Jun 16, 2016 at 2:16 PM, John Halley Gotway
<johnhg at ucar.edu>
> wrote:
>
>> Matt,
>>
>> Good news. I was finally able to replicate the behavior your
seeing.
>> If both ps_plot_flag and nc_pairs_flag are set to FALSE, then this
>> behavior occurs.
>>
>> Randy and I inspected the code and found that offending line. We
>> can't figure out how that logic made it in there. Thanks for
catching it!
>>
>> In case you're interested, the problem is the "if" statement on
line
>> 372 of the file mode_exec.cc:
>> 370 // Do matching and merging
>> 371
>> 372 if ( engine.conf_info.ps_plot_flag ||
>> !(engine.conf_info.nc_info.all_false()) ) {
>>
>> We are only performing matching/merging if that expression is true.
>> But ps_plot_flag and nc_pairs_flag don't apply. I suspect we mean
to
>> be checking different flags there.
>>
>> I need to complete the testing of the fix, and then I'll post an
>> updated set of met-5.1 patches.
>>
>> Thanks,
>> John
>>
>> On Wed, Jun 15, 2016 at 12:18 PM, 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=76735 >
>>>
>>> No problem - I'm happy to send anything I can to help diagnose the
>>> problem.
>>>
>>> To clarify a bit, when ps_flag = TRUE, and I need to run
>>> wwmca_regrid, it takes 2.5 minutes for the wwmca_regrid step and
>>> 7:10 minutes for MODE to run.
>>> When I set it ps_flag = FALSE, MODE ran it ran in 2:23.
>>>
>>> ".obj.txt" files, appended with the value of ps_flag, are
attached.
>>> You'll
>>> note they are much different files!
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Wednesday, June 15, 2016 12:48 PM
>>> To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>>> <matthew.sittel.ctr at us.af.mil>
>>> Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
>>> Output
>>>
>>> Matt,
>>>
>>> Great, thanks.
>>>
>>> Sorry to ask for so much data on this, but it would also be
helpful
>>> see the two version of the output "_obj.txt" file. The one
>>> generated with ps_flag = TRUE and the other one with ps_flag =
>>> FALSE.
>>>
>>> As for timing information, I'm surprised there is that large of a
>>> discrepancy between the two. When I run your test case, running
>>> with ps_flag = TRUE takes
>>> 4:25 while running with ps_flag = FALSE takes 3:58.
>>> 27 seconds is a significant difference, but represents only about
a
>>> 10% runtime difference.
>>>
>>> You mentioned that when ps_flag = TRUE, the runtime is 8 minutes.
>>> What is it with ps_flag = FALSE?
>>>
>>> Thanks,
>>> John
>>>
>>> On Wed, Jun 15, 2016 at 11:10 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=76735 >
>>> >
>>> > Yes it's 5.1 with the May 23 patches applied.
>>> >
>>> > Config log attached.
>>> >
>>> > -----Original Message-----
>>> > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > Sent: Wednesday, June 15, 2016 11:39 AM
>>> > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL
>>> > <matthew.sittel.ctr at us.af.mil>
>>> > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
>>> > Output
>>> >
>>> > Matt,
>>> >
>>> > Yes, that is very odd behavior.
>>> >
>>> > Let's clarify out exactly what version of MET you're running. I
>>> > know it's version 5.1, but what is the date of the latest
patches
>>> > you've
>>> applied?
>>> > Also, didn't I send you updates for wwmca_regrid? Are those
also
>>> applied?
>>> >
>>> > Lastly, can you send me the config.log file in your top-level
MET
>>> > directory?
>>> > That'll tell me the compilers used and options compiled.
>>> >
>>> > Thanks,
>>> > John
>>> >
>>> > On Wed, Jun 15, 2016 at 7:56 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=76735
>
>>> > >
>>> > > I'm positive. That was the only change I made between runs.
I
>>> > > did it multiple times yesterday and today to convince myself
>>> > > that was the
>>> > reason.
>>> > >
>>> > > Can you think of anything in the the MODE config file that
would
>>> > > force such a dependency?
>>> > >
>>> > > It's taking about 8 minutes to run WWMCA_REGRID and MODE, and
I
>>> > > need to run 480 verifications, so I'll never get this done in
a
>>> > > reasonable amount of time. While I may drop some forecast
hours
>>> > > if no solution can be found, a solution would be even better
as
>>> > > it seems the longest step is that PostScript build.
>>> > >
>>> > > -----Original Message-----
>>> > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > Sent: Tuesday, June 14, 2016 3:38 PM
>>> > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > matthew.sittel.ctr at us.af.mil>
>>> > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE .obj
>>> > > Output
>>> > >
>>> > > Matt,
>>> > >
>>> > > Wow, that is a very odd symptom! I just reran your case twice
>>> > > with "ps_plot_flag" set to TRUE and FALSE.
>>> > >
>>> > > I compared the output "_obj.txt" files and found them to be
>>> identical.
>>> > >
>>> > > Are you positive that the only configuration file change you
>>> > > made was in ps_plot_flag? If you're using environment
variables
>>> > > in the config file, please check their values to make sure
they
>>> > > are set as you
>>> > intended.
>>> > >
>>> > > So I'm not able to replicate the behavior you describe using
the
>>> > > latest
>>> > > met-5.1 bugfix release.
>>> > >
>>> > > Thanks,
>>> > > John
>>> > >
>>> > > On Tue, Jun 14, 2016 at 1:48 PM, 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=76735
>>> > > > >
>>> > > >
>>> > > > Hey John,
>>> > > >
>>> > > > This will sound bizarre, but the only way I can generate
>>> > > > meaningful numbers in the ".obj.txt" is when I have
>>> > > > "ps_plot_flag = TRUE" in the MODE config file. When I
switch
>>> > > > it to "FALSE" I
>>> get all
>>> > > > zeroes.
>>> > > >
>>> > > > Can you replicate on your side? Do I *have* to have that
flag
>>> > > > on to force the matching process to even take place? I
don't
>>> > > > need the ".ps"
>>> > > > output files, just the numbers in ".obj.txt".
>>> > > >
>>> > > > Matt
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > > Sent: Tuesday, June 14, 2016 11:26 AM
>>> > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > matthew.sittel.ctr at us.af.mil>
>>> > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
.obj
>>> > > > Output
>>> > > >
>>> > > > Matt,
>>> > > >
>>> > > > Thanks for sending the WWMCA-Regrid config file info. When
I
>>> > > > used your settings, I was able to replicate your "bad"
result.
>>> > > > The WWMCA-North and WWMCA-South grids are actually
predefined
>>> > > > in the code and named "wwma_north" and "wwmca_south". So I
>>> > > > updated the
>>> > "to_grid"
>>> > > > in your config file to read:
>>> > > > to_grid = "wwmca_north";
>>> > > >
>>> > > > Then I plotted/attached the result. I also attached the
plot
>>> > > > of the forecast data for reference. Notice that the
forecast
>>> > > > grid is upside-down and flipped relative to the WWMCA grid.
>>> > > > So you will need to use the "regrid" option when running
mode
>>> > > > to compare this data. If you pass the "fcsts_t005..." file
as
>>> > > > the forecast and the WWMCA data as the observation, my
>>> > > > suggestion would be to regrid to the
>>> > OBS
>>> > > > field.
>>> > > > That way the output will be on the conventional WWMCA North
grid.
>>> > > >
>>> > > > Please give that a shot and take a close look at both the
>>> > > > ascii output from MODE and the PostScript output.
>>> > > >
>>> > > > Hope that helps.
>>> > > >
>>> > > > John
>>> > > >
>>> > > >
>>> > > > On Tue, Jun 14, 2016 at 6:42 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=76735 >
>>> > > > >
>>> > > > > Hi John,
>>> > > > >
>>> > > > > Wow, that WWMCA is way off. Here's how I call it:
>>> > > > >
>>> > > > > ${MET_dir}/wwmca_regrid -out ${obs_nc} -config
>>> > > > > ${regrid_cfg_file} -nh ${obs_nh_met_name} -sh
>>> > > > > ${obs_sh_met_name} -v 4
>>> > > > >
>>> > > > > I pushed the NH and SH WWMCA files to the FTP site for you
>>> > > > > just now (should have thought to do that yesterday).
>>> > > > >
>>> > > > > The config file contents:
>>> > > > >
>>> > > > > regrid = {
>>> > > > > to_grid = "stereo 1024 1024 20.837 55.000 100.000
23.813
>>> > 6367.47
>>> > > 0
>>> > > > > N";
>>> > > > > vld_thresh = 0.5;
>>> > > > > method = NEAREST;
>>> > > > > width = 1;
>>> > > > > }
>>> > > > >
>>> > > > >
>>> > > > >
////////////////////////////////////////////////////////////
>>> > > > > ////
>>> > > > > //
>>> > > > > //
>>> > > > > //
>>> > > > > //////////
>>> > > > >
>>> > > > > //
>>> > > > > // NetCDF output information // variable_name =
"Cloud_Pct";
>>> > > > > units = "percent";
>>> > > > > long_name = "cloud cover percent";
>>> > > > > level = "SFC";
>>> > > > >
>>> > > > >
>>> > > > >
////////////////////////////////////////////////////////////
>>> > > > > ////
>>> > > > > //
>>> > > > > //
>>> > > > > //
>>> > > > > //////////
>>> > > > >
>>> > > > > //
>>> > > > > // Maximum pixel age in minutes //
>>> > > > > max_minutes = 1440;
>>> > > > >
>>> > > > > I'm guessing I messed up the "to_grid"? I was trying to
get
>>> > > > > it to match the model data of course.
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Matt
>>> > > > >
>>> > > > > -----Original Message-----
>>> > > > > From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> > > > > Sent: Monday, June 13, 2016 3:50 PM
>>> > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > > matthew.sittel.ctr at us.af.mil>
>>> > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over MODE
>>> > > > > .obj Output
>>> > > > >
>>> > > > > Matt,
>>> > > > >
>>> > > > > OK, here's what I've found...
>>> > > > >
>>> > > > > (1) wwmca_regrid version 5.1 writes the accumulation
>>> > > > > interval global attribute like this:
>>> > > > > Cloud_Pct:accum_time = "1 hour" ;
>>> > > > >
>>> > > > > The current development version (i.e. for the 5.2 release)
>>> > > > > writes it like
>>> > > > > this:
>>> > > > > Cloud_Pct:accum_time = "010000" ;
>>> > > > > Cloud_Pct:accum_time_sec = 3600 ;
>>> > > > >
>>> > > > > MET actually doesn't even parse the "accum_time" string.
>>> > > > > Instead, its looking for "accum_time_sec". Since that is
>>> > > > > missing, the accumulation interval is set to it's default
>>> > > > > value
>>> of bad
>>> > > > > data (i.e.
>>> > > > > a value of
>>> > > > -9999).
>>> > > > > We are failing to check for bad data and -9999 is
>>> > > > > interpreted as a number of second and converted to that
>>> > > > > weird string
>>> "-02-46-39".
>>> > > > >
>>> > > > > Version 5.2 of wwmca_regrid will store the accumulation
>>> > > > > interval in the expected way. So it won't have this bad
data issue.
>>> > > > >
>>> > > > > However, this is the second time this weird string has
popped up.
>>> > > > > I'll add some logic to check for this and write "000000"
>>> > > > > instead of
>>> > > > "-02-46-39".
>>> > > > >
>>> > > > > (2) I ran plot_data_plane on the data files you sent and
>>> > > > > have attached the resulting images in PNG format. The
GRIB1
>>> > > > > forecast looks fine but the WWMCA data does not:
>>> > > > >
>>> > > > > /d1/johnhg/MET/MET_development/
>>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>>> > > > > fcsts_t005_2016040100_036.GR1 \
>>> > > > > fcsts_t005_2016040100_036_TCDC.ps \ 'name="TCDC";
level="L0";'
>>> > > > >
>>> > > > > /d1/johnhg/MET/MET_development/
>>> > > > > svn-met-dev.cgd.ucar.edu/trunk/met/bin/plot_data_plane \
>>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.nc \
>>> > > > > REANAL_WWMCA_TOTAL_CLOUD_PCT_NH_201604021200.ps \
>>> > > > > 'name="Cloud_Pct"; level="(*,*)";'
>>> > > > >
>>> > > > > Notice how weird the WWMCA map data looks. I think we
>>> > > > > should step back and work on the wwmca_regrid output. Can
>>> > > > > you tell me what commands you used to run that one?
>>> > > > >
>>> > > > > FYI, when I ran MODE on this data, I didn't see all the
0's
>>> > > > > you were seeing. I got reasonable looking output. But
>>> > > > > let's straighten out wwmca_regrid before moving on to
that.
>>> > > > >
>>> > > > > Thanks,
>>> > > > > John
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Mon, Jun 13, 2016 at 10:31 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=76735
>>> > > > > > >
>>> > > > > >
>>> > > > > > I just posted the files in 'sittel_data'. This is using
>>> > > > > > the recently recompiled v5.1 executables.
>>> > > > > >
>>> > > > > > -----Original Message-----
>>> > > > > > From: John Halley Gotway via RT
[mailto:met_help at ucar.edu]
>>> > > > > > Sent: Monday, June 13, 2016 11:18 AM
>>> > > > > > To: SITTEL, MATTHEW C CTR USAF AFMC AFLCMC/HBAW-OL <
>>> > > > > > matthew.sittel.ctr at us.af.mil>
>>> > > > > > Subject: Re: [rt.rap.ucar.edu #76735] Confusion over
MODE
>>> > > > > > .obj Output
>>> > > > > >
>>> > > > > > Matt,
>>> > > > > >
>>> > > > > > Yes, that certainly doesn't look like very meaningful
>>> > > > > > output from
>>> > > MODE!
>>> > > > > >
>>> > > > > > Regarding the OBS_ACCUM being set to "-02-46-39", if you
>>> > > > > > do the math
>>> > > > > > -2 hours, 46 minutes, and 39 seconds equals -9999, which
>>> > > > > > curiously, is the value we use for missing data. I
>>> > > > > > strongly suspect that we're missing a check for bad data
somewhere.
>>> > > > > > When the accumulation interval is bad data (-9999), we
>>> > > > > > should either write out "000000" or "NA". Using "00000"
>>> > > > > > would likely avoid parsing headaches down the line. But
>>> > > > > > no, I don't think this has anything to do with the bad
>>> > > > > > object
>>> > > > > output you're getting.
>>> > > > > >
>>> > > > > > Are you able to send me sample files for your MODE run
>>> > > > > > (fcst, obs, and config file)? I'll run it here,
reproduce
>>> > > > > > the behavior you're seeing, and then try to figure it
out.
>>> > > > > > Could you post it to our anonymous ftp
>>> > > > > site?
>>> > > > > >
>>> > > > > > Being able to replicate the "-02-46-39" will make it
easy
>>> > > > > > for me to fix that one.
>>> > > > > >
>>> > > > > > Thanks,
>>> > > > > > John
>>> > > > > >
>>> > > > > >
>>> > > > > > On Mon, Jun 13, 2016 at 9:20 AM, SITTEL, MATTHEW C CTR
>>> > > > > > USAF AFWA
>>> > > > > > 16 WS/WXN via RT <met_help at ucar.edu> wrote:
>>> > > > > >
>>> > > > > > >
>>> > > > > > > Mon Jun 13 09:20:02 2016: Request 76735 was acted
upon.
>>> > > > > > > Transaction: Ticket created by
matthew.sittel.ctr at us.af.mil
>>> > > > > > > Queue: met_help
>>> > > > > > > Subject: Confusion over MODE .obj Output
>>> > > > > > > Owner: Nobody
>>> > > > > > > Requestors: matthew.sittel.ctr at us.af.mil
>>> > > > > > > Status: new
>>> > > > > > > Ticket <URL:
>>> > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=76735
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > Hi,
>>> > > > > > >
>>> > > > > > > I'm trying to figure out if I have a problem with the
>>> > > > > > > way I have configured MODE to run.
>>> > > > > > >
>>> > > > > > > I am attempting to build cloud objects (based on a
>>> > > > > > > threshold of cloud cover being 95% or greater) from
DCF
>>> > > > > > > cloud model data and WWMCA ground truth analyses.
>>> > > > > > >
>>> > > > > > > In the example I just ran I have entries in an output
>>> > > > > > > .obj file, one line for each of the 30 forecast
objects,
>>> > > > > > > then a line for each of 26 observation objects, and
>>> > > > > > > lines for each of the 30x26
>>> > > > > > forecast-observation pairs.
>>> > > > > > >
>>> > > > > > > Below are a few lines from the output file.
>>> > > > > > >
>>> > > > > > > VERSION MODEL FCST_LEAD FCST_VALID FCST_ACCUM
OBS_LEAD
>>> > > OBS_VALID
>>> > > > > > > OBS_ACCUM FCST_RAD FCST_THR OBS_RAD OBS_THR FCST_VAR
>>> > > > > > > FCST_LEV OBS_VAR OBS_LEV OBJECT_ID OBJECT_CAT
>>> > > > > > > CENTROID_X CENTROID_Y CENTROID_LAT CENTROID_LON
AXIS_ANG
>>> > > > > > > LENGTH WIDTH AREA AREA_FILTER AREA_THRESH CURVATURE
>>> > > > > > > CURVATURE_X CURVATURE_Y COMPLEXITY
>>> > > > > > > INTENSITY_10 INTENSITY_25
>>> > > > > > INTENSITY_50
>>> > > > > > > INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
>>> > > CENTROID_DIST
>>> > > > > > > BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF AREA_RATIO
>>> > > > > > > INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
>>> > > > > > > INTERSECTION_OVER_AREA COMPLEXITY_RATIO
>>> > > > > > > PERCENTILE_INTENSITY_RATIO
>>> > > INTEREST
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F002 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F003 CF000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O001 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O002 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC O003 CO000 0
>>> 0
>>> > > > > > > -20.837 55 0 0 0 0
0
>>> > > > 0
>>> > > > > > > 0 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0 0
0
>>> > > > > > NA
>>> > > > > > > NA NA NA NA
>>> > > NA
>>> > > > > > > NA NA NA
NA
>>> > > > > > > NA NA
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O001 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O002 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > > V5.1 DCF 360000 20160402_120000 000000
000000
>>> > > > > > > 20160402_120000 -02-46-39 8 >=95.0 8
>=95.0
>>> TCDC
>>> > > > > L0
>>> > > > > > > Cloud_Pct SFC F001_O003 CF000_CO000 NA
>>> NA
>>> > > > > NA
>>> > > > > > > NA NA NA NA NA NA
>>> > NA
>>> > > > > > > NA NA NA NA NA
>>> NA
>>> > > > > > > NA NA NA NA
NA
>>> > > > > 0
>>> > > > > > > 0 0 0 0
>>> > 0
>>> > > > > > > 0 0 0
0
>>> > > > > > > 0 0
>>> > > > > > >
>>> > > > > > > What I can't figure out is how MODE apparently
diagnosed
>>> > > > > > > 30 forecast objects and 26 observation objects, but
has
>>> > > > > > > nothing but zeroes and missing values.
>>> > > > > > >
>>> > > > > > > A couple of parts that might be of concern, or help in
>>> > diagnosing:
>>> > > > > > >
>>> > > > > > > 1. I'm not sure why OBS_ACCUM says "-02-46-39", or if
it
>>> > > > > > > is indicative of the problem.
>>> > > > > > > 2. The centroid lat/lon of each object is always the
same.
>>> > > > > > > This is a northern hemisphere product and I believe
>>> > > > > > > (-20.837,55) is a corner point for the WWMCA data.
Note
>>> > > > > > > that the WWMCA observation data are created by
WWMCA_REGRID.
>>> > > > > > >
>>> > > > > > > // SIGNED //
>>> > > > > > > Matthew C. Sittel
>>> > > > > > > University Corporation for Atmospheric Research
>>> > > > > > > 16 WS/WXN, 557 WW, Offutt AFB, NE
>>> > > > > > > matthew.sittel.ctr at us.af.mil
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>
------------------------------------------------
More information about the Met_help
mailing list