[Met_help] [rt.rap.ucar.edu #79384] History for Point Stat help
John Halley Gotway via RT
met_help at ucar.edu
Fri Mar 10 14:17:36 MST 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello MET help,
I’m going to go ahead and apologize for all the information in this email, but hopefully it will help you better diagnose what the best way for me to move forward is. As part of my research I generated 12 different WRF runs over the same week using the same I.C.s and B.C.s, and am currently in the process of comparing them against real world observations to see which config worked the best. I am primary concerned with comparing precip, surface temp/dewpoint, and surface winds.
The first tool I have tried to use has been the point stat tool. I am using your met-5.2_bugfix package and did not find any errors while/after compiling and made sure the test files, like test_point_stat.sh, all work. The data I am using is as follows:
Instead of downloading prepbufer files and converting them with the PB2NC tool, I just used the UCAR site to do it for me ( http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y>)
Request Detail:
Date Limits : 2016-08-12 00:00 2016-08-20 06:00
NCEP Verification Regions : SEC
Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR PRMSL
PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT QKSWND SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
Quality Mark Threshold : 9
File Compression : gz
Data Output Format : NETCDF
To convert my WRF data into a readable format I used P_Interp. I am now realizing this might not be the best way forward, but seemed the easiest to set up as I had to offload all my model output to a different cluster that I did not configure WRF on. I have been a bit confused as P_Interp says it can unstager data to pressure levels, but on your website it says that P_Interp cannot onstager data (at least for use with MODE and other tools). Either way do you think I should try use a different pre-processing software to unpack my WRF data or will P_Interp be sufficient to compare precip, surface temp/dewpoint and winds?
When I run my file PointStat.sh using the attached PointStatConfig1 file, I get the following data error message:
*** Running Point-Stat on prepbuffer files ***
DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_bugfix/share/met/config/PointStatConfig_default
DEBUG 1: User Config File: config/PointStatConfig
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=1
DEBUG 1: Forecast File: ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr.gdas.225564.2016081200.nc
DEBUG 2:
DEBUG 2: --------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for T2(*,*,0).
WARNING:
WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane &, double &) const -> star found in bad slot
WARNING:
ERROR :
ERROR : PinterpFile::valid_time(int) const -> range check error
ERROR :
Looking at the ncdump P_Interp File, T2 (2 meter temperature shows):
float T2(Time, south_north, west_east) ;
T2:FieldType = 104 ;
T2:MemoryOrder = "XY " ;
T2:description = "TEMP at 2 M" ;
T2:units = "K" ;
T2:stagger = "" ;
T2:coordinates = "XLONG XLAT XTIME" ;
T2:missing_value = 1.e+36f ;
I am not sure if the issue is that P_Interp is not properly extracting this information, or If I just need to change my PointStatConfig1 file.
Thanks!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
Cell: (904)-333-5427
> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu <mailto:tcram at ucar.edu>> wrote:
>
> Hi Matthew,
>
> I recommend contacting MET support (cc'd here). It's possible you should be using the PrepBUFR data instead of the NetCDF data in MET, but having no experience using MET, I am merely speculating on this. MET support should be able to help you out.
>
> Good luck,
> - Tom
>
> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew <dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> wrote:
> Hey Thomas
>
> I was able to get the data download with no issues, however I have been having issues with actually using that data in MET. I am trying to compare it to some WRF output (used P-Interp to convert into a MET readable format), but the PointStatConfig file keeps having issues (I’m not sure I filled it out correctly). Anyways I was wondering if you, or anyone happened to know of an online resource, or even someone who had a configuration set up for comparing data against WRF data so I can compare what I have against there config files and hopefully figure out where I am going wrong. I’ve been looking through the MET user guide but haven’t found a solution yet. Thanks!
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
> Cell: (904)-333-5427 <tel:%28904%29-333-5427>
>
> > On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu <mailto:tcram at ucar.edu> wrote:
> >
> > Your subset request for NCEP ADP Global Upper Air and Surface Weather Observations has completed.
> > Please login to the NCAR RDA server at http://rda.ucar.edu <http://rda.ucar.edu/>, then download your files from the
> > following URL:
> >
> > http://rda.ucar.edu/#dsrqst/DAWSON225564/ <http://rda.ucar.edu/#dsrqst/DAWSON225564/>
> >
> > Request ID: DAWSON225564
> >
> > Request Detail:
> > Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> > NCEP Verification Regions : SEC
> > Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR PRMSL
> > PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT QKSWND SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> > Quality Mark Threshold : 9
> > File Compression : gz
> > Data Output Format : NETCDF
> >
> >
> > The "rda-request-manager" command line tool provides an additional option for users to download
> > request output files on unix based systems. The "rda-request-manager" tool can be accessed at:
> >
> > http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
> >
> > The data provided in your data request are a subset of the NCAR RDA dataset ds337.0 --
> > 'NCEP ADP Global Upper Air and Surface Weather Observations (PREPBUFR format), May 1997 - Continuing'. Please see http://rda.ucar.edu/datasets/ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/> for more information.
> >
> > Your data will remain on our system for 5 days. If this is not sufficient time for you to retrieve
> > your data, please let me know as soon as possible, so that I can prevent the data files from being
> > purged too soon.
> >
> > If you have any questions related to this data request, please let me know by replying to this
> > email.
> >
> > Sincerely,
> >
> > Thomas Cram
> > NCAR/CISL/Data Support Section
> > Phone: (303)-497-1217 <tel:%28303%29-497-1217>
> > Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
> > Web: http://rda.ucar.edu <http://rda.ucar.edu/>
>
>
>
>
> --
> Thomas Cram
> NCAR / CISL / DSS
> tel: +1-303-497-1217
> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
> web: rda.ucar.edu <http://rda.ucar.edu/>
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: mgd08 at my.fsu.edu
Cell: (904)-333-5427
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Wed Feb 08 15:58:50 2017
Matthew,
I see that you have some questions about running the Point-Stat tool.
Regarding post-processing, I'd suggest switching from the pinterp
utility
to using the Unified Post-Processor (UPP). It writes output in GRIB
which
MET can easily handle. Why pinterp output could work fine for precip,
temperature, and dewpoint, MET won't be able to process the winds
since
they're defined on the staggered dimension. I realize that running
UPP,
yet another tool to compile and script up, can be a hassle. But I
think
it'll be less work in the long run.
But as for your specific error from Point-Stat, I suspect that'll be
easy
to fix. In your Point-Stat config file, try using:
name = "T2";
level = [ "(0,*,*)" ];
I often like plotting the data first:
met-5.2/bin/plot_data_plane \
../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_d01_2016-08-
12_12:00:00_PLEV
\
T2.ps \
'name="T2"; level="(0,*,*)";'
Hopefully that'll create a PostScript plot of your data.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> Transaction: Ticket created by dawsonmattg at gmail.com
> Queue: met_help
> Subject: Point Stat help
> Owner: Nobody
> Requestors: dawsonmattg at gmail.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
>
> Hello MET help,
>
> I’m going to go ahead and apologize for all the information
in
> this email, but hopefully it will help you better diagnose what the
best
> way for me to move forward is. As part of my research I generated 12
> different WRF runs over the same week using the same I.C.s and
B.C.s, and
> am currently in the process of comparing them against real world
> observations to see which config worked the best. I am primary
concerned
> with comparing precip, surface temp/dewpoint, and surface winds.
>
> The first tool I have tried to use has been the point stat
tool. I
> am using your met-5.2_bugfix package and did not find any errors
> while/after compiling and made sure the test files, like
> test_point_stat.sh, all work. The data I am using is as follows:
>
>
> Instead of downloading prepbufer files and
converting them
> with the PB2NC tool, I just used the UCAR site to do it for me (
>
http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y
> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
> subset.php?_da=y>)
> Request Detail:
> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> NCEP Verification Regions : SEC
> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
PRMSL
> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> Quality Mark Threshold : 9
> File Compression : gz
> Data Output Format : NETCDF
>
>
>
> To convert my WRF data into a readable format I used
P_Interp. I
> am now realizing this might not be the best way forward, but seemed
the
> easiest to set up as I had to offload all my model output to a
different
> cluster that I did not configure WRF on. I have been a bit confused
as
> P_Interp says it can unstager data to pressure levels, but on your
website
> it says that P_Interp cannot onstager data (at least for use with
MODE and
> other tools). Either way do you think I should try use a different
> pre-processing software to unpack my WRF data or will P_Interp be
> sufficient to compare precip, surface temp/dewpoint and winds?
>
>
>
>
> When I run my file PointStat.sh using the attached
> PointStatConfig1 file, I get the following data error message:
>
> *** Running Point-Stat on prepbuffer files ***
> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config/PointStatConfig
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=1
> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> .gdas.225564.2016081200.nc
> DEBUG 2:
> DEBUG 2:
------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Reading data for T2(*,*,0).
> WARNING:
> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
> &) const -> star found in bad slot
> WARNING:
> ERROR :
> ERROR : PinterpFile::valid_time(int) const -> range check error
> ERROR :
>
>
> Looking at the ncdump P_Interp File, T2 (2 meter temperature shows):
> float T2(Time, south_north, west_east) ;
> T2:FieldType = 104 ;
> T2:MemoryOrder = "XY " ;
> T2:description = "TEMP at 2 M" ;
> T2:units = "K" ;
> T2:stagger = "" ;
> T2:coordinates = "XLONG XLAT XTIME" ;
> T2:missing_value = 1.e+36f ;
>
> I am not sure if the issue is that P_Interp is not properly
extracting
> this information, or If I just need to change my PointStatConfig1
file.
>
>
> Thanks!
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> Cell: (904)-333-5427
>
> > On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu <mailto:
> tcram at ucar.edu>> wrote:
> >
> > Hi Matthew,
> >
> > I recommend contacting MET support (cc'd here). It's possible you
> should be using the PrepBUFR data instead of the NetCDF data in MET,
but
> having no experience using MET, I am merely speculating on this.
MET
> support should be able to help you out.
> >
> > Good luck,
> > - Tom
> >
> > On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
> <mailto:dawsonmattg at gmail.com>> wrote:
> > Hey Thomas
> >
> > I was able to get the data download with no issues, however I have
been
> having issues with actually using that data in MET. I am trying to
compare
> it to some WRF output (used P-Interp to convert into a MET readable
> format), but the PointStatConfig file keeps having issues (I’m not
sure I
> filled it out correctly). Anyways I was wondering if you, or anyone
> happened to know of an online resource, or even someone who had a
> configuration set up for comparing data against WRF data so I can
compare
> what I have against there config files and hopefully figure out
where I am
> going wrong. I’ve been looking through the MET user guide but
haven’t found
> a solution yet. Thanks!
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
> > Cell: (904)-333-5427 <tel:%28904%29-333-5427>
> >
> > > On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
> wrote:
> > >
> > > Your subset request for NCEP ADP Global Upper Air and Surface
Weather
> Observations has completed.
> > > Please login to the NCAR RDA server at http://rda.ucar.edu <
> http://rda.ucar.edu/>, then download your files from the
> > > following URL:
> > >
> > > http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
> > >
> > > Request ID: DAWSON225564
> > >
> > > Request Detail:
> > > Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> > > NCEP Verification Regions : SEC
> > > Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> PRMSL
> > > PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> > > Quality Mark Threshold : 9
> > > File Compression : gz
> > > Data Output Format : NETCDF
> > >
> > >
> > > The "rda-request-manager" command line tool provides an
additional
> option for users to download
> > > request output files on unix based systems. The "rda-request-
manager"
> tool can be accessed at:
> > >
> > > http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
> > >
> > > The data provided in your data request are a subset of the NCAR
RDA
> dataset ds337.0 --
> > > 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
> format), May 1997 - Continuing'. Please see
http://rda.ucar.edu/datasets/
> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/> for more
information.
> > >
> > > Your data will remain on our system for 5 days. If this is not
> sufficient time for you to retrieve
> > > your data, please let me know as soon as possible, so that I can
> prevent the data files from being
> > > purged too soon.
> > >
> > > If you have any questions related to this data request, please
let me
> know by replying to this
> > > email.
> > >
> > > Sincerely,
> > >
> > > Thomas Cram
> > > NCAR/CISL/Data Support Section
> > > Phone: (303)-497-1217 <tel:%28303%29-497-1217>
> > > Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
> > > Web: http://rda.ucar.edu <http://rda.ucar.edu/>
> >
> >
> >
> >
> > --
> > Thomas Cram
> > NCAR / CISL / DSS
> > tel: +1-303-497-1217
> > e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
> > web: rda.ucar.edu <http://rda.ucar.edu/>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu
> Cell: (904)-333-5427
>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Wed Feb 08 16:50:01 2017
John,
Thanks for the reply! I originally wanted to use UPP, but the cluster
I ran
my WRF models on didn’t have much space (very fast though) so I had to
offload all my data to another cluster my professor uses which isn’t
very
fast but has plenty of space. Since UPP has to have a path to my WRF
build
(excerpt below), I decided it was not feasible.
"Overview of the scripts to run the UPP Note: It is recommended that
the
user refer to the run_unipost* scripts in the script/ while reading
this
overview.
1. Set up variables:
TOP_DIR: top level directory for source codes (UPPV2.1 and WRFV3)
DOMAINPATH: directory where UPP will be run from
WRFPATH: path to your WRFV3 build; defaults to the environment
variable
used during the installation with the configure script
UNI_POST_HOME: path to your UPPV2.1 build
POSTEXEC: path to your UPPV2.1 executables”
As for the winds, my WRF output does supply 10 meter winds, which I
would
assume P_Interp would just put at the level (0,*,*), so in the case
shouldn't I be able to verify winds as well?
Anyways I tried your fix and while it does run I'm not actually
getting any
values. I'm fairly certain its because I specified the Level for the
obs
at, "P1000". I'm not sure how to specify the level as the "surface" or
10
meters though.
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for T2(0,*,*).
DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Searching 41979 observations from 6956 messages.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPUPA, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPUPA, over region FULL, for interpolation method MEDIAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPUPA, over region FULL, for interpolation method DW_MEAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPSFC, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPSFC, over region FULL, for interpolation method MEDIAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
ADPSFC, over region FULL, for interpolation method DW_MEAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
MSONET, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
MSONET, over region FULL, for interpolation method MEDIAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
MSONET, over region FULL, for interpolation method DW_MEAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
SRFSHP, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
SRFSHP, over region FULL, for interpolation method MEDIAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
SRFSHP, over region FULL, for interpolation method DW_MEAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
VADWND, over region FULL, for interpolation method NEAREST(1), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
VADWND, over region FULL, for interpolation method MEDIAN(9), using 0
pairs.
DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
VADWND, over region FULL, for interpolation method DW_MEAN(9), using 0
pairs.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V.stat
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
DEBUG 1: Output file:
../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427 <(904)%20333-5427>
On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
Matthew,
I see that you have some questions about running the Point-Stat tool.
Regarding post-processing, I'd suggest switching from the pinterp
utility
to using the Unified Post-Processor (UPP). It writes output in GRIB
which
MET can easily handle. Why pinterp output could work fine for precip,
temperature, and dewpoint, MET won't be able to process the winds
since
they're defined on the staggered dimension. I realize that running
UPP,
yet another tool to compile and script up, can be a hassle. But I
think
it'll be less work in the long run.
But as for your specific error from Point-Stat, I suspect that'll be
easy
to fix. In your Point-Stat config file, try using:
name = "T2";
level = [ "(0,*,*)" ];
I often like plotting the data first:
met-5.2/bin/plot_data_plane \
../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
d01_2016-08-12_12:00:00_PLEV
\
T2.ps \
'name="T2"; level="(0,*,*)";'
Hopefully that'll create a PostScript plot of your data.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
Transaction: Ticket created by dawsonmattg at gmail.com
Queue: met_help
Subject: Point Stat help
Owner: Nobody
Requestors: dawsonmattg at gmail.com
Status: new
Ticket <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
Hello MET help,
I’m going to go ahead and apologize for all the information in
this email, but hopefully it will help you better diagnose what the
best
way for me to move forward is. As part of my research I generated 12
different WRF runs over the same week using the same I.C.s and B.C.s,
and
am currently in the process of comparing them against real world
observations to see which config worked the best. I am primary
concerned
with comparing precip, surface temp/dewpoint, and surface winds.
The first tool I have tried to use has been the point stat
tool. I
am using your met-5.2_bugfix package and did not find any errors
while/after compiling and made sure the test files, like
test_point_stat.sh, all work. The data I am using is as follows:
Instead of downloading prepbufer files and converting
them
with the PB2NC tool, I just used the UCAR site to do it for me (
http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
subset.php?_da=y>)
Request Detail:
Date Limits : 2016-08-12 00:00 2016-08-20 06:00
NCEP Verification Regions : SEC
Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
PRMSL
PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT QKSWND
SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
Quality Mark Threshold : 9
File Compression : gz
Data Output Format : NETCDF
To convert my WRF data into a readable format I used P_Interp.
I
am now realizing this might not be the best way forward, but seemed
the
easiest to set up as I had to offload all my model output to a
different
cluster that I did not configure WRF on. I have been a bit confused as
P_Interp says it can unstager data to pressure levels, but on your
website
it says that P_Interp cannot onstager data (at least for use with MODE
and
other tools). Either way do you think I should try use a different
pre-processing software to unpack my WRF data or will P_Interp be
sufficient to compare precip, surface temp/dewpoint and winds?
When I run my file PointStat.sh using the attached
PointStatConfig1 file, I get the following data error message:
*** Running Point-Stat on prepbuffer files ***
DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
bugfix/share/met/config/PointStatConfig_default
DEBUG 1: User Config File: config/PointStatConfig
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=1
DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
.gdas.225564.2016081200.nc
DEBUG 2:
DEBUG 2: ------------------------------------------------------------
--------------------
DEBUG 2:
DEBUG 2: Reading data for T2(*,*,0).
WARNING:
WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
&) const -> star found in bad slot
WARNING:
ERROR :
ERROR : PinterpFile::valid_time(int) const -> range check error
ERROR :
Looking at the ncdump P_Interp File, T2 (2 meter temperature shows):
float T2(Time, south_north, west_east) ;
T2:FieldType = 104 ;
T2:MemoryOrder = "XY " ;
T2:description = "TEMP at 2 M" ;
T2:units = "K" ;
T2:stagger = "" ;
T2:coordinates = "XLONG XLAT XTIME" ;
T2:missing_value = 1.e+36f ;
I am not sure if the issue is that P_Interp is not properly extracting
this information, or If I just need to change my PointStatConfig1
file.
Thanks!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com
<Dawsonmattg at gmail.com>>
Cell: (904)-333-5427 <(904)%20333-5427>
On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu <mailto:
tcram at ucar.edu>> wrote:
Hi Matthew,
I recommend contacting MET support (cc'd here). It's possible you
should be using the PrepBUFR data instead of the NetCDF data in MET,
but
having no experience using MET, I am merely speculating on this. MET
support should be able to help you out.
Good luck,
- Tom
On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew <dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com <dawsonmattg at gmail.com>>> wrote:
Hey Thomas
I was able to get the data download with no issues, however I have
been
having issues with actually using that data in MET. I am trying to
compare
it to some WRF output (used P-Interp to convert into a MET readable
format), but the PointStatConfig file keeps having issues (I’m not
sure I
filled it out correctly). Anyways I was wondering if you, or anyone
happened to know of an online resource, or even someone who had a
configuration set up for comparing data against WRF data so I can
compare
what I have against there config files and hopefully figure out where
I am
going wrong. I’ve been looking through the MET user guide but haven’t
found
a solution yet. Thanks!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu <mgd08 at my.fsu.edu>>
Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
<%28904%29-333-5427>>
On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu <mailto:tcram at ucar.edu
<tcram at ucar.edu>>
wrote:
Your subset request for NCEP ADP Global Upper Air and Surface Weather
Observations has completed.
Please login to the NCAR RDA server at http://rda.ucar.edu <
http://rda.ucar.edu/>, then download your files from the
following URL:
http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
http://rda.ucar.edu/#dsrqst/DAWSON225564/>
Request ID: DAWSON225564
Request Detail:
Date Limits : 2016-08-12 00:00 2016-08-20 06:00
NCEP Verification Regions : SEC
Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
PRMSL
PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT QKSWND
SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
Quality Mark Threshold : 9
File Compression : gz
Data Output Format : NETCDF
The "rda-request-manager" command line tool provides an additional
option for users to download
request output files on unix based systems. The "rda-request-manager"
tool can be accessed at:
http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
The data provided in your data request are a subset of the NCAR RDA
dataset ds337.0 --
'NCEP ADP Global Upper Air and Surface Weather Observations (PREPBUFR
format), May 1997 - Continuing'. Please see
http://rda.ucar.edu/datasets/
ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/> for more information.
Your data will remain on our system for 5 days. If this is not
sufficient time for you to retrieve
your data, please let me know as soon as possible, so that I can
prevent the data files from being
purged too soon.
If you have any questions related to this data request, please let me
know by replying to this
email.
Sincerely,
Thomas Cram
NCAR/CISL/Data Support Section
Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
<%28303%29-497-1217>>
Email: tcram at ucar.edu <mailto:tcram at ucar.edu <tcram at ucar.edu>>
Web: http://rda.ucar.edu <http://rda.ucar.edu/>
--
Thomas Cram
NCAR / CISL / DSS
tel: +1-303-497-1217 <(303)%20497-1217>
e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu <tcram at ucar.edu>>
web: rda.ucar.edu <http://rda.ucar.edu/>
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: mgd08 at my.fsu.edu
Cell: (904)-333-5427 <(904)%20333-5427>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Wed Feb 08 17:03:05 2017
Matthew,
The verification of surface variables is done in a pretty simplistic
way by
specifying the message type.
The ADPSFC and SFCSHP message types are assumed to exist at the
surface and
are used to verifying "surface" variables such as 2m temperature and
10-m
winds. And ONLYSF is a short-cut for combining land-based ADPSFC and
water-based SFCSHP observations together. Your Point-Stat config file
should look something like this:
fcst = {
field = [
{
name = "T2";
level = [ "(*,*,0)" ];
cat_thresh = [ <=273, >273 ];
}
];
}
obs = {
message_type = [ "ADPSFC" ];
sid_exc = [];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ <=273, >273 ];
}
];
}
Does that produce any matched pairs? I don't see the source of the
PREPBUFR observation data you're using, but if you're using GDAS,
please
read the NOTE at the bottom of this page about the quality marker
that's
assigned to surface observations:
http://www.dtcenter.org/met/users/downloads/observation_data.php
Thanks,
John
John
On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> John,
>
> Thanks for the reply! I originally wanted to use UPP, but the
cluster I ran
> my WRF models on didn’t have much space (very fast though) so I had
to
> offload all my data to another cluster my professor uses which isn’t
very
> fast but has plenty of space. Since UPP has to have a path to my WRF
build
> (excerpt below), I decided it was not feasible.
>
> "Overview of the scripts to run the UPP Note: It is recommended that
the
> user refer to the run_unipost* scripts in the script/ while reading
this
> overview.
> 1. Set up variables:
> TOP_DIR: top level directory for source codes (UPPV2.1 and WRFV3)
> DOMAINPATH: directory where UPP will be run from
> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
> used during the installation with the configure script
> UNI_POST_HOME: path to your UPPV2.1 build
> POSTEXEC: path to your UPPV2.1 executables”
>
> As for the winds, my WRF output does supply 10 meter winds, which I
would
> assume P_Interp would just put at the level (0,*,*), so in the case
> shouldn't I be able to verify winds as well?
>
> Anyways I tried your fix and while it does run I'm not actually
getting any
> values. I'm fairly certain its because I specified the Level for the
obs
> at, "P1000". I'm not sure how to specify the level as the "surface"
or 10
> meters though.
>
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Reading data for T2(0,*,*).
> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Searching 41979 observations from 6956 messages.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427 <(904)%20333-5427>
>
> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT
<met_help at ucar.edu>
> wrote:
>
> Matthew,
>
> I see that you have some questions about running the Point-Stat
tool.
>
> Regarding post-processing, I'd suggest switching from the pinterp
utility
> to using the Unified Post-Processor (UPP). It writes output in GRIB
which
> MET can easily handle. Why pinterp output could work fine for
precip,
> temperature, and dewpoint, MET won't be able to process the winds
since
> they're defined on the staggered dimension. I realize that running
UPP,
> yet another tool to compile and script up, can be a hassle. But I
think
> it'll be less work in the long run.
>
> But as for your specific error from Point-Stat, I suspect that'll be
easy
> to fix. In your Point-Stat config file, try using:
> name = "T2";
> level = [ "(0,*,*)" ];
>
> I often like plotting the data first:
> met-5.2/bin/plot_data_plane \
> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> d01_2016-08-12_12:00:00_PLEV
> \
> T2.ps \
> 'name="T2"; level="(0,*,*)";'
>
> Hopefully that'll create a PostScript plot of your data.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
>
> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com via RT <
> met_help at ucar.edu> wrote:
>
>
> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> Transaction: Ticket created by dawsonmattg at gmail.com
> Queue: met_help
> Subject: Point Stat help
> Owner: Nobody
> Requestors: dawsonmattg at gmail.com
> Status: new
> Ticket <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
>
>
>
> Hello MET help,
>
> I’m going to go ahead and apologize for all the information
in
> this email, but hopefully it will help you better diagnose what the
best
> way for me to move forward is. As part of my research I generated 12
> different WRF runs over the same week using the same I.C.s and
B.C.s, and
> am currently in the process of comparing them against real world
> observations to see which config worked the best. I am primary
concerned
> with comparing precip, surface temp/dewpoint, and surface winds.
>
> The first tool I have tried to use has been the point stat
tool. I
> am using your met-5.2_bugfix package and did not find any errors
> while/after compiling and made sure the test files, like
> test_point_stat.sh, all work. The data I am using is as follows:
>
>
> Instead of downloading prepbufer files and converting
them
> with the PB2NC tool, I just used the UCAR site to do it for me (
>
http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y
> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
> subset.php?_da=y>)
> Request Detail:
> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> NCEP Verification Regions : SEC
> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
PRMSL
> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> Quality Mark Threshold : 9
> File Compression : gz
> Data Output Format : NETCDF
>
>
>
> To convert my WRF data into a readable format I used
P_Interp. I
> am now realizing this might not be the best way forward, but seemed
the
> easiest to set up as I had to offload all my model output to a
different
> cluster that I did not configure WRF on. I have been a bit confused
as
> P_Interp says it can unstager data to pressure levels, but on your
website
> it says that P_Interp cannot onstager data (at least for use with
MODE and
> other tools). Either way do you think I should try use a different
> pre-processing software to unpack my WRF data or will P_Interp be
> sufficient to compare precip, surface temp/dewpoint and winds?
>
>
>
>
> When I run my file PointStat.sh using the attached
> PointStatConfig1 file, I get the following data error message:
>
> *** Running Point-Stat on prepbuffer files ***
> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config/PointStatConfig
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=1
> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> .gdas.225564.2016081200.nc
> DEBUG 2:
> DEBUG 2:
------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Reading data for T2(*,*,0).
> WARNING:
> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
> &) const -> star found in bad slot
> WARNING:
> ERROR :
> ERROR : PinterpFile::valid_time(int) const -> range check error
> ERROR :
>
>
> Looking at the ncdump P_Interp File, T2 (2 meter temperature shows):
> float T2(Time, south_north, west_east) ;
> T2:FieldType = 104 ;
> T2:MemoryOrder = "XY " ;
> T2:description = "TEMP at 2 M" ;
> T2:units = "K" ;
> T2:stagger = "" ;
> T2:coordinates = "XLONG XLAT XTIME" ;
> T2:missing_value = 1.e+36f ;
>
> I am not sure if the issue is that P_Interp is not properly
extracting
> this information, or If I just need to change my PointStatConfig1
file.
>
>
> Thanks!
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com
> <Dawsonmattg at gmail.com>>
> Cell: (904)-333-5427 <(904)%20333-5427>
>
> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu <mailto:
>
> tcram at ucar.edu>> wrote:
>
>
> Hi Matthew,
>
> I recommend contacting MET support (cc'd here). It's possible you
>
> should be using the PrepBUFR data instead of the NetCDF data in MET,
but
> having no experience using MET, I am merely speculating on this.
MET
> support should be able to help you out.
>
>
> Good luck,
> - Tom
>
> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
>
> <mailto:dawsonmattg at gmail.com <dawsonmattg at gmail.com>>> wrote:
>
> Hey Thomas
>
> I was able to get the data download with no issues, however I have
been
>
> having issues with actually using that data in MET. I am trying to
compare
> it to some WRF output (used P-Interp to convert into a MET readable
> format), but the PointStatConfig file keeps having issues (I’m not
sure I
> filled it out correctly). Anyways I was wondering if you, or anyone
> happened to know of an online resource, or even someone who had a
> configuration set up for comparing data against WRF data so I can
compare
> what I have against there config files and hopefully figure out
where I am
> going wrong. I’ve been looking through the MET user guide but
haven’t found
> a solution yet. Thanks!
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu <mgd08 at my.fsu.edu>>
> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
> <%28904%29-333-5427>>
>
> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu <mailto:tcram at ucar.edu
> <tcram at ucar.edu>>
>
> wrote:
>
>
> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>
> Observations has completed.
>
> Please login to the NCAR RDA server at http://rda.ucar.edu <
>
> http://rda.ucar.edu/>, then download your files from the
>
> following URL:
>
> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>
> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
>
>
> Request ID: DAWSON225564
>
> Request Detail:
> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> NCEP Verification Regions : SEC
> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
>
> PRMSL
>
> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>
> Quality Mark Threshold : 9
> File Compression : gz
> Data Output Format : NETCDF
>
>
> The "rda-request-manager" command line tool provides an additional
>
> option for users to download
>
> request output files on unix based systems. The "rda-request-
manager"
>
> tool can be accessed at:
>
>
> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
>
> The data provided in your data request are a subset of the NCAR RDA
>
> dataset ds337.0 --
>
> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>
> format), May 1997 - Continuing'. Please see
http://rda.ucar.edu/datasets/
> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/> for more
information.
>
>
> Your data will remain on our system for 5 days. If this is not
>
> sufficient time for you to retrieve
>
> your data, please let me know as soon as possible, so that I can
>
> prevent the data files from being
>
> purged too soon.
>
> If you have any questions related to this data request, please let
me
>
> know by replying to this
>
> email.
>
> Sincerely,
>
> Thomas Cram
> NCAR/CISL/Data Support Section
> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
> <%28303%29-497-1217>>
> Email: tcram at ucar.edu <mailto:tcram at ucar.edu <tcram at ucar.edu>>
> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
>
>
>
>
>
> --
> Thomas Cram
> NCAR / CISL / DSS
> tel: +1-303-497-1217 <(303)%20497-1217>
> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu <tcram at ucar.edu>>
> web: rda.ucar.edu <http://rda.ucar.edu/>
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu
> Cell: (904)-333-5427 <(904)%20333-5427>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Sat Feb 18 11:15:35 2017
Hey John,
Sorry for the late reply, but your suggestion worked! I also figured
out I was referencing the wrong file time which of course would come
back with no results.
I was curious though how you would suggest tackling my “project". I
have 12 different model outputs (the same domain) over the same week
that I want to try verify. The model output occurs at 15 min
intervals, and I am primary interested in precipitation skill scores
(would like to use the MODE tool), but the temperature, Td, wind speed
and direction will also be useful. I was planing on using the MODE
tool to evaluate the SFC precip to stage II radar data unless you
would recommend another way. Also please let me know if you would like
me to add you in my acknowledgement section for help with this tool
kit, thanks!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>
> According to our records, your request has been resolved. If you
have any
> further questions or concerns, please respond to this message.
On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT
<met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
Matthew,
The verification of surface variables is done in a pretty simplistic
way by
specifying the message type.
The ADPSFC and SFCSHP message types are assumed to exist at the
surface and
are used to verifying "surface" variables such as 2m temperature and
10-m
winds. And ONLYSF is a short-cut for combining land-based ADPSFC and
water-based SFCSHP observations together. Your Point-Stat config file
should look something like this:
fcst = {
field = [
{
name = "T2";
level = [ "(*,*,0)" ];
cat_thresh = [ <=273, >273 ];
}
];
}
obs = {
message_type = [ "ADPSFC" ];
sid_exc = [];
field = [
{
name = "TMP";
level = [ "Z2" ];
cat_thresh = [ <=273, >273 ];
}
];
}
Does that produce any matched pairs? I don't see the source of the
PREPBUFR observation data you're using, but if you're using GDAS,
please
read the NOTE at the bottom of this page about the quality marker
that's
assigned to surface observations:
http://www.dtcenter.org/met/users/downloads/observation_data.php
<http://www.dtcenter.org/met/users/downloads/observation_data.php>
Thanks,
John
John
On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> via RT <
met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>
> John,
>
> Thanks for the reply! I originally wanted to use UPP, but the
cluster I ran
> my WRF models on didn’t have much space (very fast though) so I had
to
> offload all my data to another cluster my professor uses which isn’t
very
> fast but has plenty of space. Since UPP has to have a path to my WRF
build
> (excerpt below), I decided it was not feasible.
>
> "Overview of the scripts to run the UPP Note: It is recommended that
the
> user refer to the run_unipost* scripts in the script/ while reading
this
> overview.
> 1. Set up variables:
> TOP_DIR: top level directory for source codes (UPPV2.1 and WRFV3)
> DOMAINPATH: directory where UPP will be run from
> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
> used during the installation with the configure script
> UNI_POST_HOME: path to your UPPV2.1 build
> POSTEXEC: path to your UPPV2.1 executables”
>
> As for the winds, my WRF output does supply 10 meter winds, which I
would
> assume P_Interp would just put at the level (0,*,*), so in the case
> shouldn't I be able to verify winds as well?
>
> Anyways I tried your fix and while it does run I'm not actually
getting any
> values. I'm fairly certain its because I specified the Level for the
obs
> at, "P1000". I'm not sure how to specify the level as the "surface"
or 10
> meters though.
>
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Reading data for T2(0,*,*).
> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Searching 41979 observations from 6956 messages.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> ADPSFC, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> MSONET, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> SRFSHP, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method NEAREST(1), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method MEDIAN(9), using
0
> pairs.
> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation type
> VADWND, over region FULL, for interpolation method DW_MEAN(9), using
0
> pairs.
> DEBUG 2:
> DEBUG 2:
> ------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> DEBUG 1: Output file:
> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> Cell: (904)-333-5427 <(904)%20333-5427>
>
> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT
<met_help at ucar.edu <mailto:met_help at ucar.edu>>
> wrote:
>
> Matthew,
>
> I see that you have some questions about running the Point-Stat
tool.
>
> Regarding post-processing, I'd suggest switching from the pinterp
utility
> to using the Unified Post-Processor (UPP). It writes output in GRIB
which
> MET can easily handle. Why pinterp output could work fine for
precip,
> temperature, and dewpoint, MET won't be able to process the winds
since
> they're defined on the staggered dimension. I realize that running
UPP,
> yet another tool to compile and script up, can be a hassle. But I
think
> it'll be less work in the long run.
>
> But as for your specific error from Point-Stat, I suspect that'll be
easy
> to fix. In your Point-Stat config file, try using:
> name = "T2";
> level = [ "(0,*,*)" ];
>
> I often like plotting the data first:
> met-5.2/bin/plot_data_plane \
> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> d01_2016-08-12_12:00:00_PLEV
> \
> T2.ps \
> 'name="T2"; level="(0,*,*)";'
>
> Hopefully that'll create a PostScript plot of your data.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu <mailto:met_help at ucar.edu>
>
>
> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> via RT <
> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>
>
> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> Transaction: Ticket created by dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com>
> Queue: met_help
> Subject: Point Stat help
> Owner: Nobody
> Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
> Status: new
> Ticket <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>
>
> Hello MET help,
>
> I’m going to go ahead and apologize for all the information in
> this email, but hopefully it will help you better diagnose what the
best
> way for me to move forward is. As part of my research I generated 12
> different WRF runs over the same week using the same I.C.s and
B.C.s, and
> am currently in the process of comparing them against real world
> observations to see which config worked the best. I am primary
concerned
> with comparing precip, surface temp/dewpoint, and surface winds.
>
> The first tool I have tried to use has been the point stat
tool. I
> am using your met-5.2_bugfix package and did not find any errors
> while/after compiling and made sure the test files, like
> test_point_stat.sh, all work. The data I am using is as follows:
>
>
> Instead of downloading prepbufer files and converting
them
> with the PB2NC tool, I just used the UCAR site to do it for me (
>
http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_subset.php?_da=y>
> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>
> subset.php?_da=y>)
> Request Detail:
> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> NCEP Verification Regions : SEC
> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
PRMSL
> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> Quality Mark Threshold : 9
> File Compression : gz
> Data Output Format : NETCDF
>
>
>
> To convert my WRF data into a readable format I used P_Interp.
I
> am now realizing this might not be the best way forward, but seemed
the
> easiest to set up as I had to offload all my model output to a
different
> cluster that I did not configure WRF on. I have been a bit confused
as
> P_Interp says it can unstager data to pressure levels, but on your
website
> it says that P_Interp cannot onstager data (at least for use with
MODE and
> other tools). Either way do you think I should try use a different
> pre-processing software to unpack my WRF data or will P_Interp be
> sufficient to compare precip, surface temp/dewpoint and winds?
>
>
>
>
> When I run my file PointStat.sh using the attached
> PointStatConfig1 file, I get the following data error message:
>
> *** Running Point-Stat on prepbuffer files ***
> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> bugfix/share/met/config/PointStatConfig_default
> DEBUG 1: User Config File: config/PointStatConfig
> GSL_RNG_TYPE=mt19937
> GSL_RNG_SEED=1
> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> .gdas.225564.2016081200.nc
> DEBUG 2:
> DEBUG 2:
------------------------------------------------------------
> --------------------
> DEBUG 2:
> DEBUG 2: Reading data for T2(*,*,0).
> WARNING:
> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
> &) const -> star found in bad slot
> WARNING:
> ERROR :
> ERROR : PinterpFile::valid_time(int) const -> range check error
> ERROR :
>
>
> Looking at the ncdump P_Interp File, T2 (2 meter temperature shows):
> float T2(Time, south_north, west_east) ;
> T2:FieldType = 104 ;
> T2:MemoryOrder = "XY " ;
> T2:description = "TEMP at 2 M" ;
> T2:units = "K" ;
> T2:stagger = "" ;
> T2:coordinates = "XLONG XLAT XTIME" ;
> T2:missing_value = 1.e+36f ;
>
> I am not sure if the issue is that P_Interp is not properly
extracting
> this information, or If I just need to change my PointStatConfig1
file.
>
>
> Thanks!
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>
> Cell: (904)-333-5427 <(904)%20333-5427>
>
> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:tcram at ucar.edu> <mailto:
>
> tcram at ucar.edu <mailto:tcram at ucar.edu>>> wrote:
>
>
> Hi Matthew,
>
> I recommend contacting MET support (cc'd here). It's possible you
>
> should be using the PrepBUFR data instead of the NetCDF data in MET,
but
> having no experience using MET, I am merely speculating on this.
MET
> support should be able to help you out.
>
>
> Good luck,
> - Tom
>
> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
>
> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>> wrote:
>
> Hey Thomas
>
> I was able to get the data download with no issues, however I have
been
>
> having issues with actually using that data in MET. I am trying to
compare
> it to some WRF output (used P-Interp to convert into a MET readable
> format), but the PointStatConfig file keeps having issues (I’m not
sure I
> filled it out correctly). Anyways I was wondering if you, or anyone
> happened to know of an online resource, or even someone who had a
> configuration set up for comparing data against WRF data so I can
compare
> what I have against there config files and hopefully figure out
where I am
> going wrong. I’ve been looking through the MET user guide but
haven’t found
> a solution yet. Thanks!
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>>>
> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
<tel:%28904%29-333-5427>
> <%28904%29-333-5427>>
>
> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
> <tcram at ucar.edu <mailto:tcram at ucar.edu>>>
>
> wrote:
>
>
> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>
> Observations has completed.
>
> Please login to the NCAR RDA server at http://rda.ucar.edu
<http://rda.ucar.edu/> <
>
> http://rda.ucar.edu/ <http://rda.ucar.edu/>>, then download your
files from the
>
> following URL:
>
> http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/DAWSON225564/> <
>
> http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/DAWSON225564/>>
>
>
> Request ID: DAWSON225564
>
> Request Detail:
> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> NCEP Verification Regions : SEC
> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH MIXR
>
> PRMSL
>
> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>
> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>
> Quality Mark Threshold : 9
> File Compression : gz
> Data Output Format : NETCDF
>
>
> The "rda-request-manager" command line tool provides an additional
>
> option for users to download
>
> request output files on unix based systems. The "rda-request-
manager"
>
> tool can be accessed at:
>
>
> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
<http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>
>
> The data provided in your data request are a subset of the NCAR RDA
>
> dataset ds337.0 --
>
> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>
> format), May 1997 - Continuing'. Please see
http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>
> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/ds337.0/>> for more information.
>
>
> Your data will remain on our system for 5 days. If this is not
>
> sufficient time for you to retrieve
>
> your data, please let me know as soon as possible, so that I can
>
> prevent the data files from being
>
> purged too soon.
>
> If you have any questions related to this data request, please let
me
>
> know by replying to this
>
> email.
>
> Sincerely,
>
> Thomas Cram
> NCAR/CISL/Data Support Section
> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
<tel:%28303%29-497-1217>
> <%28303%29-497-1217>>
> Email: tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu> <tcram at ucar.edu <mailto:tcram at ucar.edu>>>
> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <http://rda.ucar.edu/>>
>
>
>
>
>
> --
> Thomas Cram
> NCAR / CISL / DSS
> tel: +1-303-497-1217 <(303)%20497-1217>
> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu <mailto:tcram at ucar.edu> <tcram at ucar.edu
<mailto:tcram at ucar.edu>>>
> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/
<http://rda.ucar.edu/>>
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
> Cell: (904)-333-5427 <(904)%20333-5427>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Tue Feb 21 14:06:49 2017
Matthew,
Great, I'm glad you were able to get it up and running!
There's no need to acknowledge me directly, but I'd appreciate you
acknowledging the MET software package. The more advertising we can
get
for future funding, the better!
As for your choice of verification datasets, that's usually limited by
your
domain, the timing of your model output, and the actual verification
questions you're trying to answer. With output from 12 different
models,
what are you actually trying to assess? Is it just a scorecard to see
which model verifies better overall? Or do you have more specific
questions? With only one week of data to compare, you can do an
objective
comparison... but will your results hold up during the other 3
seasons? Or
during other weather regimes? So I'd be hesitant in using only one
week of
data to make strong claims about overall performance.
With data every 15 minutes, I believe that the surface data shows up
pretty
in PREPBUFR pretty regularly. So you could do surface verification up
to
every 15 minutes if you'd like. While there are a very small number
of
soundings in PREPBUFR files at off-hours, we generally only verify
upper-air at 00Z and 12Z.
For choice of precipitation analysis... I'd suggest reading about
StageII,
StageIV, CCPA, and MRMS. We've used all of them on different projects
within the DTC. MRMS is probably the one being most actively worked
on
right now. Depending on what questions you're asking, you could also
compare against URMA which is a gridded CONUS analysis product.
Let me warn you that I'm a software engineer, not a statistician or
atmospheric scientist. But we do have both of them on the MET team.
So if
you have specific questions in those areas, I could route them to the
right
person.
Hope that helps.
Thanks,
John
On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> Hey John,
>
> Sorry for the late reply, but your suggestion worked! I also
> figured out I was referencing the wrong file time which of course
would
> come back with no results.
>
> I was curious though how you would suggest tackling my
“project".
> I have 12 different model outputs (the same domain) over the same
week that
> I want to try verify. The model output occurs at 15 min intervals,
and I am
> primary interested in precipitation skill scores (would like to use
the
> MODE tool), but the temperature, Td, wind speed and direction will
also be
> useful. I was planing on using the MODE tool to evaluate the SFC
precip to
> stage II radar data unless you would recommend another way. Also
please let
> me know if you would like me to add you in my acknowledgement
section for
> help with this tool kit, thanks!
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
> > On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
> >
> > According to our records, your request has been resolved. If you
have any
> > further questions or concerns, please respond to this message.
>
>
>
>
> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>> wrote:
>
> Matthew,
>
> The verification of surface variables is done in a pretty simplistic
way by
> specifying the message type.
>
> The ADPSFC and SFCSHP message types are assumed to exist at the
surface and
> are used to verifying "surface" variables such as 2m temperature and
10-m
> winds. And ONLYSF is a short-cut for combining land-based ADPSFC
and
> water-based SFCSHP observations together. Your Point-Stat config
file
> should look something like this:
>
> fcst = {
> field = [
> {
> name = "T2";
> level = [ "(*,*,0)" ];
> cat_thresh = [ <=273, >273 ];
> }
> ];
> }
>
> obs = {
> message_type = [ "ADPSFC" ];
> sid_exc = [];
>
> field = [
> {
> name = "TMP";
> level = [ "Z2" ];
> cat_thresh = [ <=273, >273 ];
> }
> ];
> }
>
> Does that produce any matched pairs? I don't see the source of the
> PREPBUFR observation data you're using, but if you're using GDAS,
please
> read the NOTE at the bottom of this page about the quality marker
that's
> assigned to surface observations:
> http://www.dtcenter.org/met/users/downloads/observation_data.php <
> http://www.dtcenter.org/met/users/downloads/observation_data.php>
>
> Thanks,
> John
>
>
>
>
> John
>
> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> via RT <
> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
> >
> > John,
> >
> > Thanks for the reply! I originally wanted to use UPP, but the
cluster I
> ran
> > my WRF models on didn’t have much space (very fast though) so I
had to
> > offload all my data to another cluster my professor uses which
isn’t very
> > fast but has plenty of space. Since UPP has to have a path to my
WRF
> build
> > (excerpt below), I decided it was not feasible.
> >
> > "Overview of the scripts to run the UPP Note: It is recommended
that the
> > user refer to the run_unipost* scripts in the script/ while
reading this
> > overview.
> > 1. Set up variables:
> > TOP_DIR: top level directory for source codes (UPPV2.1 and WRFV3)
> > DOMAINPATH: directory where UPP will be run from
> > WRFPATH: path to your WRFV3 build; defaults to the environment
variable
> > used during the installation with the configure script
> > UNI_POST_HOME: path to your UPPV2.1 build
> > POSTEXEC: path to your UPPV2.1 executables”
> >
> > As for the winds, my WRF output does supply 10 meter winds, which
I would
> > assume P_Interp would just put at the level (0,*,*), so in the
case
> > shouldn't I be able to verify winds as well?
> >
> > Anyways I tried your fix and while it does run I'm not actually
getting
> any
> > values. I'm fairly certain its because I specified the Level for
the obs
> > at, "P1000". I'm not sure how to specify the level as the
"surface" or 10
> > meters though.
> >
> > DEBUG 2:
> > ------------------------------------------------------------
> > --------------------
> > DEBUG 2:
> > DEBUG 2: Reading data for T2(0,*,*).
> > DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
levels.
> > DEBUG 2:
> > DEBUG 2:
> > ------------------------------------------------------------
> > --------------------
> > DEBUG 2:
> > DEBUG 2: Searching 41979 observations from 6956 messages.
> > DEBUG 2:
> > DEBUG 2:
> > ------------------------------------------------------------
> > --------------------
> > DEBUG 2:
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
> > pairs.
> > DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> > VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
> > pairs.
> > DEBUG 2:
> > DEBUG 2:
> > ------------------------------------------------------------
> > --------------------
> > DEBUG 2:
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> > DEBUG 1: Output file:
> > ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
> >
> >
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> > Cell: (904)-333-5427 <(904)%20333-5427>
> >
> > On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT
<met_help at ucar.edu
> <mailto:met_help at ucar.edu>>
> > wrote:
> >
> > Matthew,
> >
> > I see that you have some questions about running the Point-Stat
tool.
> >
> > Regarding post-processing, I'd suggest switching from the pinterp
utility
> > to using the Unified Post-Processor (UPP). It writes output in
GRIB
> which
> > MET can easily handle. Why pinterp output could work fine for
precip,
> > temperature, and dewpoint, MET won't be able to process the winds
since
> > they're defined on the staggered dimension. I realize that
running UPP,
> > yet another tool to compile and script up, can be a hassle. But I
think
> > it'll be less work in the long run.
> >
> > But as for your specific error from Point-Stat, I suspect that'll
be easy
> > to fix. In your Point-Stat config file, try using:
> > name = "T2";
> > level = [ "(0,*,*)" ];
> >
> > I often like plotting the data first:
> > met-5.2/bin/plot_data_plane \
> > ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> > d01_2016-08-12_12:00:00_PLEV
> > \
> > T2.ps \
> > 'name="T2"; level="(0,*,*)";'
> >
> > Hopefully that'll create a PostScript plot of your data.
> >
> > Thanks,
> > John Halley Gotway
> > met_help at ucar.edu <mailto:met_help at ucar.edu>
> >
> >
> > On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> via RT <
> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >
> >
> > Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> > Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com>
> > Queue: met_help
> > Subject: Point Stat help
> > Owner: Nobody
> > Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
> >
> >
> > Hello MET help,
> >
> > I’m going to go ahead and apologize for all the information
in
> > this email, but hopefully it will help you better diagnose what
the best
> > way for me to move forward is. As part of my research I generated
12
> > different WRF runs over the same week using the same I.C.s and
B.C.s, and
> > am currently in the process of comparing them against real world
> > observations to see which config worked the best. I am primary
concerned
> > with comparing precip, surface temp/dewpoint, and surface winds.
> >
> > The first tool I have tried to use has been the point stat
tool. I
> > am using your met-5.2_bugfix package and did not find any errors
> > while/after compiling and made sure the test files, like
> > test_point_stat.sh, all work. The data I am using is as follows:
> >
> >
> > Instead of downloading prepbufer files and
converting them
> > with the PB2NC tool, I just used the UCAR site to do it for me (
> > http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su
> bset.php?_da=y <http://rda.ucar.edu/datasets/
> ds337.0/index.html#forms/337_subset.php?_da=y>
> > <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>
> > subset.php?_da=y>)
> > Request Detail:
> > Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> > NCEP Verification Regions : SEC
> > Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR PRMSL
> > PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> > SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> > Quality Mark Threshold : 9
> > File Compression : gz
> > Data Output Format : NETCDF
> >
> >
> >
> > To convert my WRF data into a readable format I used
P_Interp. I
> > am now realizing this might not be the best way forward, but
seemed the
> > easiest to set up as I had to offload all my model output to a
different
> > cluster that I did not configure WRF on. I have been a bit
confused as
> > P_Interp says it can unstager data to pressure levels, but on your
> website
> > it says that P_Interp cannot onstager data (at least for use with
MODE
> and
> > other tools). Either way do you think I should try use a different
> > pre-processing software to unpack my WRF data or will P_Interp be
> > sufficient to compare precip, surface temp/dewpoint and winds?
> >
> >
> >
> >
> > When I run my file PointStat.sh using the attached
> > PointStatConfig1 file, I get the following data error message:
> >
> > *** Running Point-Stat on prepbuffer files ***
> > DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> > bugfix/share/met/config/PointStatConfig_default
> > DEBUG 1: User Config File: config/PointStatConfig
> > GSL_RNG_TYPE=mt19937
> > GSL_RNG_SEED=1
> > DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> > ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> > DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> > .gdas.225564.2016081200.nc
> > DEBUG 2:
> > DEBUG 2:
------------------------------------------------------------
> > --------------------
> > DEBUG 2:
> > DEBUG 2: Reading data for T2(*,*,0).
> > WARNING:
> > WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
> double
> > &) const -> star found in bad slot
> > WARNING:
> > ERROR :
> > ERROR : PinterpFile::valid_time(int) const -> range check error
> > ERROR :
> >
> >
> > Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
> > float T2(Time, south_north, west_east) ;
> > T2:FieldType = 104 ;
> > T2:MemoryOrder = "XY " ;
> > T2:description = "TEMP at 2 M" ;
> > T2:units = "K" ;
> > T2:stagger = "" ;
> > T2:coordinates = "XLONG XLAT XTIME" ;
> > T2:missing_value = 1.e+36f ;
> >
> > I am not sure if the issue is that P_Interp is not properly
extracting
> > this information, or If I just need to change my PointStatConfig1
file.
> >
> >
> > Thanks!
> >
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> > <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>
> > Cell: (904)-333-5427 <(904)%20333-5427>
> >
> > On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu <mailto:
> tcram at ucar.edu> <mailto:
> >
> > tcram at ucar.edu <mailto:tcram at ucar.edu>>> wrote:
> >
> >
> > Hi Matthew,
> >
> > I recommend contacting MET support (cc'd here). It's possible you
> >
> > should be using the PrepBUFR data instead of the NetCDF data in
MET, but
> > having no experience using MET, I am merely speculating on this.
MET
> > support should be able to help you out.
> >
> >
> > Good luck,
> > - Tom
> >
> > On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
> <mailto:dawsonmattg at gmail.com>
> >
> > <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <
> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>> wrote:
> >
> > Hey Thomas
> >
> > I was able to get the data download with no issues, however I have
been
> >
> > having issues with actually using that data in MET. I am trying to
> compare
> > it to some WRF output (used P-Interp to convert into a MET
readable
> > format), but the PointStatConfig file keeps having issues (I’m not
sure I
> > filled it out correctly). Anyways I was wondering if you, or
anyone
> > happened to know of an online resource, or even someone who had a
> > configuration set up for comparing data against WRF data so I can
compare
> > what I have against there config files and hopefully figure out
where I
> am
> > going wrong. I’ve been looking through the MET user guide but
haven’t
> found
> > a solution yet. Thanks!
> >
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mgd08 at my.fsu.edu
<mailto:
> mgd08 at my.fsu.edu>>>
> > Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
> <tel:%28904%29-333-5427>
> > <%28904%29-333-5427>>
> >
> > On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
> > <tcram at ucar.edu <mailto:tcram at ucar.edu>>>
> >
> > wrote:
> >
> >
> > Your subset request for NCEP ADP Global Upper Air and Surface
Weather
> >
> > Observations has completed.
> >
> > Please login to the NCAR RDA server at http://rda.ucar.edu <
> http://rda.ucar.edu/> <
> >
> > http://rda.ucar.edu/ <http://rda.ucar.edu/>>, then download your
files
> from the
> >
> > following URL:
> >
> > http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/D
> AWSON225564/> <
> >
> > http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/D
> AWSON225564/>>
> >
> >
> > Request ID: DAWSON225564
> >
> > Request Detail:
> > Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> > NCEP Verification Regions : SEC
> > Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> >
> > PRMSL
> >
> > PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> >
> > SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >
> > Quality Mark Threshold : 9
> > File Compression : gz
> > Data Output Format : NETCDF
> >
> >
> > The "rda-request-manager" command line tool provides an additional
> >
> > option for users to download
> >
> > request output files on unix based systems. The "rda-request-
manager"
> >
> > tool can be accessed at:
> >
> >
> > http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>
> >
> > The data provided in your data request are a subset of the NCAR
RDA
> >
> > dataset ds337.0 --
> >
> > 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
> >
> > format), May 1997 - Continuing'. Please see
> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>
> > ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
> http://rda.ucar.edu/datasets/ds337.0/>> for more information.
> >
> >
> > Your data will remain on our system for 5 days. If this is not
> >
> > sufficient time for you to retrieve
> >
> > your data, please let me know as soon as possible, so that I can
> >
> > prevent the data files from being
> >
> > purged too soon.
> >
> > If you have any questions related to this data request, please let
me
> >
> > know by replying to this
> >
> > email.
> >
> > Sincerely,
> >
> > Thomas Cram
> > NCAR/CISL/Data Support Section
> > Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
> <tel:%28303%29-497-1217>
> > <%28303%29-497-1217>>
> > Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu> <tcram at ucar.edu <mailto:tcram at ucar.edu>>>
> > Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
> http://rda.ucar.edu/>>
> >
> >
> >
> >
> >
> > --
> > Thomas Cram
> > NCAR / CISL / DSS
> > tel: +1-303-497-1217 <(303)%20497-1217>
> > e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu> <tcram at ucar.edu <mailto:tcram at ucar.edu>>>
> > web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/ <
> http://rda.ucar.edu/>>
> >
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
> > Cell: (904)-333-5427 <(904)%20333-5427>
>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Tue Feb 21 20:56:25 2017
John,
Thanks for all the good info! Heres a little scoop on what I am trying
to accomplish if your interested, if not I have answers to your
questions starting at **********
You might be familiar with the AMU (Applied Meteorology Unit
https://science.ksc.nasa.gov/amu/history.html
<https://science.ksc.nasa.gov/amu/history.html>) that is down in cape
canaveral. They were tasked with setting up a mesoscale model to
improve operational forecast, and ran a few different verification
statistics (ME, RMSE, MODE) on a number of different configurations
your interested here a link to their first Technical Report
(Watson_2013-https://ntrs.nasa.gov/search.jsp?R=20150000384
<https://ntrs.nasa.gov/search.jsp?R=20150000384> ). Several changes
have occurred over the past few years included triple nested model as
opposed to double nested, smaller grid space, and a myriad of
additional observations/assimilated data sets Watson_2014-
https://ntrs.nasa.gov/search.jsp?R=20150000384
<https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
https://ntrs.nasa.gov/search.jsp?R=20160007687
<https://ntrs.nasa.gov/search.jsp?R=20160007687> .
Talking with the head civilian down their, lightning delays are their
primary problem, as well as forecasting convection in SE flow. So
after reading up on their configuration it seemed like using a more up
to date Microphysical model would produce better precipitation
statistics and a better overall approximation of developing
convection. So I used 3 different microphysics schemes to create 12
different model runs, which show some reasonable difference when
plotting rain totals ect.
************
So with the 12 different models I am trying to create a “scorecard” to
show which ones more accurately predicted the surface precipitation,
wind speed, direction, T, Td.
The week of model runs were purposely selected over a period
predominantly SE flow (august) which they have trouble forecasting
for. This is somewhat of a sub-regime in their overall summertime
regime, but since most convection is characterized by mesoscale
process (sea-breeze, river-breeze) it could be extended for the entire
summer months. The model was PRIMARY developed to help summertime
forecast as lightning delays cost them lots of $$$, so I’m not even
sure if they rely on this model, as opposed to some of the national
centers, during other seasons.
Since the prior work from the above papers used ME, RMSE in the point
stat tool and MODE for precip I want to try use the same techniques.
I guess my real question would be how I should go about setting
everything up, coding.
I would like to have RMSE, ME( T, Td, wind direction, speed) and MODE
(precip) values for each day and for the total week. Since my wrf
outfiles are in 15 min intervals, over 24 hours I’m not sure how to
specify in point stat how to read in all these files and produce one
RMSE and ME value for the day, or produce them for each time and them
calculate the total for the day. I’m not sure if I need to somehow
mesh all my wrfout files into one file and then have point stat use
that or if there is a simpler way.
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>
> Matthew,
>
> Great, I'm glad you were able to get it up and running!
>
> There's no need to acknowledge me directly, but I'd appreciate you
> acknowledging the MET software package. The more advertising we can
get
> for future funding, the better!
>
> As for your choice of verification datasets, that's usually limited
by your
> domain, the timing of your model output, and the actual verification
> questions you're trying to answer. With output from 12 different
models,
> what are you actually trying to assess? Is it just a scorecard to
see
> which model verifies better overall? Or do you have more specific
> questions? With only one week of data to compare, you can do an
objective
> comparison... but will your results hold up during the other 3
seasons? Or
> during other weather regimes? So I'd be hesitant in using only one
week of
> data to make strong claims about overall performance.
>
> With data every 15 minutes, I believe that the surface data shows up
pretty
> in PREPBUFR pretty regularly. So you could do surface verification
up to
> every 15 minutes if you'd like. While there are a very small number
of
> soundings in PREPBUFR files at off-hours, we generally only verify
> upper-air at 00Z and 12Z.
>
> For choice of precipitation analysis... I'd suggest reading about
StageII,
> StageIV, CCPA, and MRMS. We've used all of them on different
projects
> within the DTC. MRMS is probably the one being most actively worked
on
> right now. Depending on what questions you're asking, you could
also
> compare against URMA which is a gridded CONUS analysis product.
>
> Let me warn you that I'm a software engineer, not a statistician or
> atmospheric scientist. But we do have both of them on the MET team.
So if
> you have specific questions in those areas, I could route them to
the right
> person.
>
> Hope that helps.
>
> Thanks,
> John
>
>
>
> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> via RT <
> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>>
>> Hey John,
>>
>> Sorry for the late reply, but your suggestion worked! I also
>> figured out I was referencing the wrong file time which of course
would
>> come back with no results.
>>
>> I was curious though how you would suggest tackling my
“project".
>> I have 12 different model outputs (the same domain) over the same
week that
>> I want to try verify. The model output occurs at 15 min intervals,
and I am
>> primary interested in precipitation skill scores (would like to use
the
>> MODE tool), but the temperature, Td, wind speed and direction will
also be
>> useful. I was planing on using the MODE tool to evaluate the SFC
precip to
>> stage II radar data unless you would recommend another way. Also
please let
>> me know if you would like me to add you in my acknowledgement
section for
>> help with this tool kit, thanks!
>>
>> Matthew G. Dawson, Capt, USAF
>> AFIT Student, Civilian Institution Program
>> Email: Dawsonmattg at gmail.com
>> Cell: (904)-333-5427
>>
>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>>
>>> According to our records, your request has been resolved. If you
have any
>>> further questions or concerns, please respond to this message.
>>
>>
>>
>>
>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT
<met_help at ucar.edu
>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>
>> Matthew,
>>
>> The verification of surface variables is done in a pretty
simplistic way by
>> specifying the message type.
>>
>> The ADPSFC and SFCSHP message types are assumed to exist at the
surface and
>> are used to verifying "surface" variables such as 2m temperature
and 10-m
>> winds. And ONLYSF is a short-cut for combining land-based ADPSFC
and
>> water-based SFCSHP observations together. Your Point-Stat config
file
>> should look something like this:
>>
>> fcst = {
>> field = [
>> {
>> name = "T2";
>> level = [ "(*,*,0)" ];
>> cat_thresh = [ <=273, >273 ];
>> }
>> ];
>> }
>>
>> obs = {
>> message_type = [ "ADPSFC" ];
>> sid_exc = [];
>>
>> field = [
>> {
>> name = "TMP";
>> level = [ "Z2" ];
>> cat_thresh = [ <=273, >273 ];
>> }
>> ];
>> }
>>
>> Does that produce any matched pairs? I don't see the source of the
>> PREPBUFR observation data you're using, but if you're using GDAS,
please
>> read the NOTE at the bottom of this page about the quality marker
that's
>> assigned to surface observations:
>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<http://www.dtcenter.org/met/users/downloads/observation_data.php> <
>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<http://www.dtcenter.org/met/users/downloads/observation_data.php>>
>>
>> Thanks,
>> John
>>
>>
>>
>>
>> John
>>
>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> <mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>
>>> John,
>>>
>>> Thanks for the reply! I originally wanted to use UPP, but the
cluster I
>> ran
>>> my WRF models on didn’t have much space (very fast though) so I
had to
>>> offload all my data to another cluster my professor uses which
isn’t very
>>> fast but has plenty of space. Since UPP has to have a path to my
WRF
>> build
>>> (excerpt below), I decided it was not feasible.
>>>
>>> "Overview of the scripts to run the UPP Note: It is recommended
that the
>>> user refer to the run_unipost* scripts in the script/ while
reading this
>>> overview.
>>> 1. Set up variables:
>>> TOP_DIR: top level directory for source codes (UPPV2.1 and WRFV3)
>>> DOMAINPATH: directory where UPP will be run from
>>> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
>>> used during the installation with the configure script
>>> UNI_POST_HOME: path to your UPPV2.1 build
>>> POSTEXEC: path to your UPPV2.1 executables”
>>>
>>> As for the winds, my WRF output does supply 10 meter winds, which
I would
>>> assume P_Interp would just put at the level (0,*,*), so in the
case
>>> shouldn't I be able to verify winds as well?
>>>
>>> Anyways I tried your fix and while it does run I'm not actually
getting
>> any
>>> values. I'm fairly certain its because I specified the Level for
the obs
>>> at, "P1000". I'm not sure how to specify the level as the
"surface" or 10
>>> meters though.
>>>
>>> DEBUG 2:
>>> ------------------------------------------------------------
>>> --------------------
>>> DEBUG 2:
>>> DEBUG 2: Reading data for T2(0,*,*).
>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
levels.
>>> DEBUG 2:
>>> DEBUG 2:
>>> ------------------------------------------------------------
>>> --------------------
>>> DEBUG 2:
>>> DEBUG 2: Searching 41979 observations from 6956 messages.
>>> DEBUG 2:
>>> DEBUG 2:
>>> ------------------------------------------------------------
>>> --------------------
>>> DEBUG 2:
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
>>> pairs.
>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>> pairs.
>>> DEBUG 2:
>>> DEBUG 2:
>>> ------------------------------------------------------------
>>> --------------------
>>> DEBUG 2:
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
>>> DEBUG 1: Output file:
>>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>>>
>>>
>>>
>>> Matthew G. Dawson, Capt, USAF
>>> AFIT Student, Civilian Institution Program
>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>
>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT
<met_help at ucar.edu <mailto:met_help at ucar.edu>
>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
>>> wrote:
>>>
>>> Matthew,
>>>
>>> I see that you have some questions about running the Point-Stat
tool.
>>>
>>> Regarding post-processing, I'd suggest switching from the pinterp
utility
>>> to using the Unified Post-Processor (UPP). It writes output in
GRIB
>> which
>>> MET can easily handle. Why pinterp output could work fine for
precip,
>>> temperature, and dewpoint, MET won't be able to process the winds
since
>>> they're defined on the staggered dimension. I realize that
running UPP,
>>> yet another tool to compile and script up, can be a hassle. But I
think
>>> it'll be less work in the long run.
>>>
>>> But as for your specific error from Point-Stat, I suspect that'll
be easy
>>> to fix. In your Point-Stat config file, try using:
>>> name = "T2";
>>> level = [ "(0,*,*)" ];
>>>
>>> I often like plotting the data first:
>>> met-5.2/bin/plot_data_plane \
>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
>>> d01_2016-08-12_12:00:00_PLEV
>>> \
>>> T2.ps \
>>> 'name="T2"; level="(0,*,*)";'
>>>
>>> Hopefully that'll create a PostScript plot of your data.
>>>
>>> Thanks,
>>> John Halley Gotway
>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>
>>>
>>>
>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> <mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>>
>>>
>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
>>> Transaction: Ticket created by dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com> <mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>> Queue: met_help
>>> Subject: Point Stat help
>>> Owner: Nobody
>>> Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>
>>>
>>> Hello MET help,
>>>
>>> I’m going to go ahead and apologize for all the information
in
>>> this email, but hopefully it will help you better diagnose what
the best
>>> way for me to move forward is. As part of my research I generated
12
>>> different WRF runs over the same week using the same I.C.s and
B.C.s, and
>>> am currently in the process of comparing them against real world
>>> observations to see which config worked the best. I am primary
concerned
>>> with comparing precip, surface temp/dewpoint, and surface winds.
>>>
>>> The first tool I have tried to use has been the point stat
tool. I
>>> am using your met-5.2_bugfix package and did not find any errors
>>> while/after compiling and made sure the test files, like
>>> test_point_stat.sh, all work. The data I am using is as follows:
>>>
>>>
>>> Instead of downloading prepbufer files and converting
them
>>> with the PB2NC tool, I just used the UCAR site to do it for me (
>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
>> bset.php?_da=y <http://rda.ucar.edu/datasets/
<http://rda.ucar.edu/datasets/>
>> ds337.0/index.html#forms/337_subset.php?_da=y>
>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_
<http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
>>> subset.php?_da=y>)
>>> Request Detail:
>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>> NCEP Verification Regions : SEC
>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR PRMSL
>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>> Quality Mark Threshold : 9
>>> File Compression : gz
>>> Data Output Format : NETCDF
>>>
>>>
>>>
>>> To convert my WRF data into a readable format I used
P_Interp. I
>>> am now realizing this might not be the best way forward, but
seemed the
>>> easiest to set up as I had to offload all my model output to a
different
>>> cluster that I did not configure WRF on. I have been a bit
confused as
>>> P_Interp says it can unstager data to pressure levels, but on your
>> website
>>> it says that P_Interp cannot onstager data (at least for use with
MODE
>> and
>>> other tools). Either way do you think I should try use a different
>>> pre-processing software to unpack my WRF data or will P_Interp be
>>> sufficient to compare precip, surface temp/dewpoint and winds?
>>>
>>>
>>>
>>>
>>> When I run my file PointStat.sh using the attached
>>> PointStatConfig1 file, I get the following data error message:
>>>
>>> *** Running Point-Stat on prepbuffer files ***
>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
>>> bugfix/share/met/config/PointStatConfig_default
>>> DEBUG 1: User Config File: config/PointStatConfig
>>> GSL_RNG_TYPE=mt19937
>>> GSL_RNG_SEED=1
>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
>>> .gdas.225564.2016081200.nc
>>> DEBUG 2:
>>> DEBUG 2:
------------------------------------------------------------
>>> --------------------
>>> DEBUG 2:
>>> DEBUG 2: Reading data for T2(*,*,0).
>>> WARNING:
>>> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
>> double
>>> &) const -> star found in bad slot
>>> WARNING:
>>> ERROR :
>>> ERROR : PinterpFile::valid_time(int) const -> range check error
>>> ERROR :
>>>
>>>
>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
>>> float T2(Time, south_north, west_east) ;
>>> T2:FieldType = 104 ;
>>> T2:MemoryOrder = "XY " ;
>>> T2:description = "TEMP at 2 M" ;
>>> T2:units = "K" ;
>>> T2:stagger = "" ;
>>> T2:coordinates = "XLONG XLAT XTIME" ;
>>> T2:missing_value = 1.e+36f ;
>>>
>>> I am not sure if the issue is that P_Interp is not properly
extracting
>>> this information, or If I just need to change my PointStatConfig1
file.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Matthew G. Dawson, Capt, USAF
>>> AFIT Student, Civilian Institution Program
>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>
>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:tcram at ucar.edu> <mailto:
>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
>>>
>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>> wrote:
>>>
>>>
>>> Hi Matthew,
>>>
>>> I recommend contacting MET support (cc'd here). It's possible you
>>>
>>> should be using the PrepBUFR data instead of the NetCDF data in
MET, but
>>> having no experience using MET, I am merely speculating on this.
MET
>>> support should be able to help you out.
>>>
>>>
>>> Good luck,
>>> - Tom
>>>
>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>
>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>>
wrote:
>>>
>>> Hey Thomas
>>>
>>> I was able to get the data download with no issues, however I have
been
>>>
>>> having issues with actually using that data in MET. I am trying to
>> compare
>>> it to some WRF output (used P-Interp to convert into a MET
readable
>>> format), but the PointStatConfig file keeps having issues (I’m not
sure I
>>> filled it out correctly). Anyways I was wondering if you, or
anyone
>>> happened to know of an online resource, or even someone who had a
>>> configuration set up for comparing data against WRF data so I can
compare
>>> what I have against there config files and hopefully figure out
where I
>> am
>>> going wrong. I’ve been looking through the MET user guide but
haven’t
>> found
>>> a solution yet. Thanks!
>>>
>>>
>>> Matthew G. Dawson, Capt, USAF
>>> AFIT Student, Civilian Institution Program
>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
<tel:%28904%29-333-5427>
>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
>>> <%28904%29-333-5427>>
>>>
>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>
>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
>>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>
>>> wrote:
>>>
>>>
>>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>>>
>>> Observations has completed.
>>>
>>> Please login to the NCAR RDA server at http://rda.ucar.edu
<http://rda.ucar.edu/> <
>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
>>>
>>> http://rda.ucar.edu/ <http://rda.ucar.edu/> <http://rda.ucar.edu/
<http://rda.ucar.edu/>>>, then download your files
>> from the
>>>
>>> following URL:
>>>
>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D <http://rda.ucar.edu/#dsrqst/D>
>> AWSON225564/> <
>>>
>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/
<http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D <http://rda.ucar.edu/#dsrqst/D>
>> AWSON225564/>>
>>>
>>>
>>> Request ID: DAWSON225564
>>>
>>> Request Detail:
>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>> NCEP Verification Regions : SEC
>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>>>
>>> PRMSL
>>>
>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>
>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>
>>> Quality Mark Threshold : 9
>>> File Compression : gz
>>> Data Output Format : NETCDF
>>>
>>>
>>> The "rda-request-manager" command line tool provides an additional
>>>
>>> option for users to download
>>>
>>> request output files on unix based systems. The "rda-request-
manager"
>>>
>>> tool can be accessed at:
>>>
>>>
>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
<http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>
<http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
>>>
>>> The data provided in your data request are a subset of the NCAR
RDA
>>>
>>> dataset ds337.0 --
>>>
>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>>>
>>> format), May 1997 - Continuing'. Please see
>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>
<http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/ds337.0/> <
>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/ds337.0/>>> for more information.
>>>
>>>
>>> Your data will remain on our system for 5 days. If this is not
>>>
>>> sufficient time for you to retrieve
>>>
>>> your data, please let me know as soon as possible, so that I can
>>>
>>> prevent the data files from being
>>>
>>> purged too soon.
>>>
>>> If you have any questions related to this data request, please let
me
>>>
>>> know by replying to this
>>>
>>> email.
>>>
>>> Sincerely,
>>>
>>> Thomas Cram
>>> NCAR/CISL/Data Support Section
>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
<tel:%28303%29-497-1217>
>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
>>> <%28303%29-497-1217>>
>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
<mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Thomas Cram
>>> NCAR / CISL / DSS
>>> tel: +1-303-497-1217 <(303)%20497-1217>
>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
<mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/
<http://rda.ucar.edu/>> <http://rda.ucar.edu/ <http://rda.ucar.edu/> <
>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>
>>>
>>> Matthew G. Dawson, Capt, USAF
>>> AFIT Student, Civilian Institution Program
>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
>>> Cell: (904)-333-5427 <(904)%20333-5427>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Wed Feb 22 09:32:04 2017
Matthew,
Sounds like an interesting project. Yes, the MET tools can be used to
perform the individual comparisons, but there remains a lot of work to
be
done to script up the calls to them in the right order to accomplish
your
task.
I've done a lot of that type of work using PERL and shell scripts
(mostly
ksh). I think we've gotten to the point in the development of the MET
software, that setting up the controlling scripts is the biggest
hurdle to
using the software. In the last few months we've begun work on a
system
we're calling MET+ which is a set of python wrapper scripts for the
MET
tools to "automate" this scripting as much as possible. This work is
driven mainly by the needs of the operational modelling community.
But
hopefully, a user, like yourself, would be able to set up a
configuration
script which the python wrapper scripts use to call the MET tools in
the
right order. But that's down the road. For now, you're stuck doing
it
yourself using whatever scripting language you prefer.
It sounds like you're interested in continuous statistics (ME, RMSE)
for
surface variables and categorical stats (MODE objects and maybe ETS)
for
precip. You'd ultimately use Point-Stat for surface point-based
verification, Grid-Stat for categorical verification of precip, and
MODE
for an object-based evaluation of precip. While you could run Point-
Stat
for every 15 minute output, that may be overkill. I'd suggest doing
it
hourly, unless there's a good reason to do it more often.
You run Point-Stat, Grid-Stat, and MODE once for each combination of
model
and output time. So you'll do many runs of those tools. From Point-
Stat,
you want the CNT line type (continuous stats) as well as the SL1L2 and
VL1L2 line types (scalar and vector parial sums) which can be
aggregated
later. You could consider dumping the individual matched pair values
(MPR
line type) but that can get to be a lot of data very quickly. From
Grid-Stat, you want the CTC and CTS line type (contingency table
counts and
statistics). Prior to running Point-Stat, you'd run PB2NC to pre-
process
PREPBUFR point observations. And prior to running Grid-Stat or MODE
you
may need to run pcp_combine if you need to change the accumulation
intervals of your precip data. Lastly, the STAT-Analysis tool is used
to
read the output of Point-Stat and Grid-Stat and accumulate statistics
over
the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
lines from each run and derive aggregated statistics. Similarly, it
can be
used to aggregate CTC lines from each run and derive aggregated
categorical
statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
(FBIAS).
So lots of little steps to accomplish, but once you get the calls
scripted
up, hopefully it'll go smoothly for you.
Hope that helps.
Thanks,
John
On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> John,
>
> Thanks for all the good info! Heres a little scoop on what I am
trying to
> accomplish if your interested, if not I have answers to your
questions
> starting at **********
>
> You might be familiar with the AMU (Applied Meteorology Unit
> https://science.ksc.nasa.gov/amu/history.html <
> https://science.ksc.nasa.gov/amu/history.html>) that is down in cape
> canaveral. They were tasked with setting up a mesoscale model to
improve
> operational forecast, and ran a few different verification
statistics (ME,
> RMSE, MODE) on a number of different configurations your interested
here a
> link to their first Technical Report (Watson_2013-https://ntrs.
> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
> jsp?R=20150000384> ). Several changes have occurred over the past
few
> years included triple nested model as opposed to double nested,
smaller
> grid space, and a myriad of additional observations/assimilated data
sets
> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
>
> Talking with the head civilian down their, lightning delays are
their
> primary problem, as well as forecasting convection in SE flow. So
after
> reading up on their configuration it seemed like using a more up to
date
> Microphysical model would produce better precipitation statistics
and a
> better overall approximation of developing convection. So I used 3
> different microphysics schemes to create 12 different model runs,
which
> show some reasonable difference when plotting rain totals ect.
>
> ************
> So with the 12 different models I am trying to create a “scorecard”
to
> show which ones more accurately predicted the surface precipitation,
wind
> speed, direction, T, Td.
>
> The week of model runs were purposely selected over a period
predominantly
> SE flow (august) which they have trouble forecasting for. This is
somewhat
> of a sub-regime in their overall summertime regime, but since most
> convection is characterized by mesoscale process (sea-breeze, river-
breeze)
> it could be extended for the entire summer months. The model was
PRIMARY
> developed to help summertime forecast as lightning delays cost them
lots of
> $$$, so I’m not even sure if they rely on this model, as opposed to
some of
> the national centers, during other seasons.
>
> Since the prior work from the above papers used ME, RMSE in the
point stat
> tool and MODE for precip I want to try use the same techniques.
>
> I guess my real question would be how I should go about setting
everything
> up, coding.
>
> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
> (precip) values for each day and for the total week. Since my wrf
outfiles
> are in 15 min intervals, over 24 hours I’m not sure how to specify
in point
> stat how to read in all these files and produce one RMSE and ME
value for
> the day, or produce them for each time and them calculate the total
for the
> day. I’m not sure if I need to somehow mesh all my wrfout files into
one
> file and then have point stat use that or if there is a simpler way.
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
> > On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
> >
> > Matthew,
> >
> > Great, I'm glad you were able to get it up and running!
> >
> > There's no need to acknowledge me directly, but I'd appreciate you
> > acknowledging the MET software package. The more advertising we
can get
> > for future funding, the better!
> >
> > As for your choice of verification datasets, that's usually
limited by
> your
> > domain, the timing of your model output, and the actual
verification
> > questions you're trying to answer. With output from 12 different
models,
> > what are you actually trying to assess? Is it just a scorecard to
see
> > which model verifies better overall? Or do you have more specific
> > questions? With only one week of data to compare, you can do an
> objective
> > comparison... but will your results hold up during the other 3
seasons?
> Or
> > during other weather regimes? So I'd be hesitant in using only
one week
> of
> > data to make strong claims about overall performance.
> >
> > With data every 15 minutes, I believe that the surface data shows
up
> pretty
> > in PREPBUFR pretty regularly. So you could do surface
verification up to
> > every 15 minutes if you'd like. While there are a very small
number of
> > soundings in PREPBUFR files at off-hours, we generally only verify
> > upper-air at 00Z and 12Z.
> >
> > For choice of precipitation analysis... I'd suggest reading about
> StageII,
> > StageIV, CCPA, and MRMS. We've used all of them on different
projects
> > within the DTC. MRMS is probably the one being most actively
worked on
> > right now. Depending on what questions you're asking, you could
also
> > compare against URMA which is a gridded CONUS analysis product.
> >
> > Let me warn you that I'm a software engineer, not a statistician
or
> > atmospheric scientist. But we do have both of them on the MET
team. So
> if
> > you have specific questions in those areas, I could route them to
the
> right
> > person.
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> via RT <
> > met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
> >>
> >> Hey John,
> >>
> >> Sorry for the late reply, but your suggestion worked! I
also
> >> figured out I was referencing the wrong file time which of course
would
> >> come back with no results.
> >>
> >> I was curious though how you would suggest tackling my
“project".
> >> I have 12 different model outputs (the same domain) over the same
week
> that
> >> I want to try verify. The model output occurs at 15 min
intervals, and
> I am
> >> primary interested in precipitation skill scores (would like to
use the
> >> MODE tool), but the temperature, Td, wind speed and direction
will also
> be
> >> useful. I was planing on using the MODE tool to evaluate the SFC
precip
> to
> >> stage II radar data unless you would recommend another way. Also
please
> let
> >> me know if you would like me to add you in my acknowledgement
section
> for
> >> help with this tool kit, thanks!
> >>
> >> Matthew G. Dawson, Capt, USAF
> >> AFIT Student, Civilian Institution Program
> >> Email: Dawsonmattg at gmail.com
> >> Cell: (904)-333-5427
> >>
> >>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu> wrote:
> >>>
> >>> According to our records, your request has been resolved. If you
have
> any
> >>> further questions or concerns, please respond to this message.
> >>
> >>
> >>
> >>
> >> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
> met_help at ucar.edu
> >> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
> >>
> >> Matthew,
> >>
> >> The verification of surface variables is done in a pretty
simplistic
> way by
> >> specifying the message type.
> >>
> >> The ADPSFC and SFCSHP message types are assumed to exist at the
surface
> and
> >> are used to verifying "surface" variables such as 2m temperature
and
> 10-m
> >> winds. And ONLYSF is a short-cut for combining land-based ADPSFC
and
> >> water-based SFCSHP observations together. Your Point-Stat config
file
> >> should look something like this:
> >>
> >> fcst = {
> >> field = [
> >> {
> >> name = "T2";
> >> level = [ "(*,*,0)" ];
> >> cat_thresh = [ <=273, >273 ];
> >> }
> >> ];
> >> }
> >>
> >> obs = {
> >> message_type = [ "ADPSFC" ];
> >> sid_exc = [];
> >>
> >> field = [
> >> {
> >> name = "TMP";
> >> level = [ "Z2" ];
> >> cat_thresh = [ <=273, >273 ];
> >> }
> >> ];
> >> }
> >>
> >> Does that produce any matched pairs? I don't see the source of
the
> >> PREPBUFR observation data you're using, but if you're using GDAS,
please
> >> read the NOTE at the bottom of this page about the quality marker
that's
> >> assigned to surface observations:
> >> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
> http://www.dtcenter.org/met/users/downloads/observation_data.php> <
> >> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
> http://www.dtcenter.org/met/users/downloads/observation_data.php>>
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >>
> >> John
> >>
> >> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> <mailto:
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
> <mailto:met_help at ucar.edu>>> wrote:
> >>
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>
> >>> John,
> >>>
> >>> Thanks for the reply! I originally wanted to use UPP, but the
cluster I
> >> ran
> >>> my WRF models on didn’t have much space (very fast though) so I
had to
> >>> offload all my data to another cluster my professor uses which
isn’t
> very
> >>> fast but has plenty of space. Since UPP has to have a path to my
WRF
> >> build
> >>> (excerpt below), I decided it was not feasible.
> >>>
> >>> "Overview of the scripts to run the UPP Note: It is recommended
that
> the
> >>> user refer to the run_unipost* scripts in the script/ while
reading
> this
> >>> overview.
> >>> 1. Set up variables:
> >>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
> >>> DOMAINPATH: directory where UPP will be run from
> >>> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
> >>> used during the installation with the configure script
> >>> UNI_POST_HOME: path to your UPPV2.1 build
> >>> POSTEXEC: path to your UPPV2.1 executables”
> >>>
> >>> As for the winds, my WRF output does supply 10 meter winds,
which I
> would
> >>> assume P_Interp would just put at the level (0,*,*), so in the
case
> >>> shouldn't I be able to verify winds as well?
> >>>
> >>> Anyways I tried your fix and while it does run I'm not actually
getting
> >> any
> >>> values. I'm fairly certain its because I specified the Level for
the
> obs
> >>> at, "P1000". I'm not sure how to specify the level as the
"surface" or
> 10
> >>> meters though.
> >>>
> >>> DEBUG 2:
> >>> ------------------------------------------------------------
> >>> --------------------
> >>> DEBUG 2:
> >>> DEBUG 2: Reading data for T2(0,*,*).
> >>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
> levels.
> >>> DEBUG 2:
> >>> DEBUG 2:
> >>> ------------------------------------------------------------
> >>> --------------------
> >>> DEBUG 2:
> >>> DEBUG 2: Searching 41979 observations from 6956 messages.
> >>> DEBUG 2:
> >>> DEBUG 2:
> >>> ------------------------------------------------------------
> >>> --------------------
> >>> DEBUG 2:
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
> >>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
> >>> pairs.
> >>> DEBUG 2:
> >>> DEBUG 2:
> >>> ------------------------------------------------------------
> >>> --------------------
> >>> DEBUG 2:
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> >>> DEBUG 1: Output file:
> >>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> >>> DEBUG 1: Output file:
> >>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> >>> DEBUG 1: Output file:
> >>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
> >>>
> >>>
> >>>
> >>> Matthew G. Dawson, Capt, USAF
> >>> AFIT Student, Civilian Institution Program
> >>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>
> >>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
> met_help at ucar.edu <mailto:met_help at ucar.edu>
> >> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
> >>> wrote:
> >>>
> >>> Matthew,
> >>>
> >>> I see that you have some questions about running the Point-Stat
tool.
> >>>
> >>> Regarding post-processing, I'd suggest switching from the
pinterp
> utility
> >>> to using the Unified Post-Processor (UPP). It writes output in
GRIB
> >> which
> >>> MET can easily handle. Why pinterp output could work fine for
precip,
> >>> temperature, and dewpoint, MET won't be able to process the
winds since
> >>> they're defined on the staggered dimension. I realize that
running
> UPP,
> >>> yet another tool to compile and script up, can be a hassle. But
I
> think
> >>> it'll be less work in the long run.
> >>>
> >>> But as for your specific error from Point-Stat, I suspect
that'll be
> easy
> >>> to fix. In your Point-Stat config file, try using:
> >>> name = "T2";
> >>> level = [ "(0,*,*)" ];
> >>>
> >>> I often like plotting the data first:
> >>> met-5.2/bin/plot_data_plane \
> >>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> >>> d01_2016-08-12_12:00:00_PLEV
> >>> \
> >>> T2.ps \
> >>> 'name="T2"; level="(0,*,*)";'
> >>>
> >>> Hopefully that'll create a PostScript plot of your data.
> >>>
> >>> Thanks,
> >>> John Halley Gotway
> >>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
> <mailto:met_help at ucar.edu>>
> >>>
> >>>
> >>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> <mailto:
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
> <mailto:met_help at ucar.edu>>> wrote:
> >>>
> >>>
> >>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> >>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
> dawsonmattg at gmail.com> <mailto:
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>> Queue: met_help
> >>> Subject: Point Stat help
> >>> Owner: Nobody
> >>> Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>> Status: new
> >>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>
> >>>
> >>> Hello MET help,
> >>>
> >>> I’m going to go ahead and apologize for all the information
in
> >>> this email, but hopefully it will help you better diagnose what
the
> best
> >>> way for me to move forward is. As part of my research I
generated 12
> >>> different WRF runs over the same week using the same I.C.s and
B.C.s,
> and
> >>> am currently in the process of comparing them against real world
> >>> observations to see which config worked the best. I am primary
> concerned
> >>> with comparing precip, surface temp/dewpoint, and surface winds.
> >>>
> >>> The first tool I have tried to use has been the point stat
tool. I
> >>> am using your met-5.2_bugfix package and did not find any errors
> >>> while/after compiling and made sure the test files, like
> >>> test_point_stat.sh, all work. The data I am using is as follows:
> >>>
> >>>
> >>> Instead of downloading prepbufer files and
converting them
> >>> with the PB2NC tool, I just used the UCAR site to do it for me
(
> >>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su <
> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
> >> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
> http://rda.ucar.edu/datasets/>
> >> ds337.0/index.html#forms/337_subset.php?_da=y>
> >>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
> >> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
> >>> subset.php?_da=y>)
> >>> Request Detail:
> >>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>> NCEP Verification Regions : SEC
> >>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> PRMSL
> >>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> >>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>> Quality Mark Threshold : 9
> >>> File Compression : gz
> >>> Data Output Format : NETCDF
> >>>
> >>>
> >>>
> >>> To convert my WRF data into a readable format I used
P_Interp. I
> >>> am now realizing this might not be the best way forward, but
seemed the
> >>> easiest to set up as I had to offload all my model output to a
> different
> >>> cluster that I did not configure WRF on. I have been a bit
confused as
> >>> P_Interp says it can unstager data to pressure levels, but on
your
> >> website
> >>> it says that P_Interp cannot onstager data (at least for use
with MODE
> >> and
> >>> other tools). Either way do you think I should try use a
different
> >>> pre-processing software to unpack my WRF data or will P_Interp
be
> >>> sufficient to compare precip, surface temp/dewpoint and winds?
> >>>
> >>>
> >>>
> >>>
> >>> When I run my file PointStat.sh using the attached
> >>> PointStatConfig1 file, I get the following data error message:
> >>>
> >>> *** Running Point-Stat on prepbuffer files ***
> >>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> >>> bugfix/share/met/config/PointStatConfig_default
> >>> DEBUG 1: User Config File: config/PointStatConfig
> >>> GSL_RNG_TYPE=mt19937
> >>> GSL_RNG_SEED=1
> >>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> >>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> >>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> >>> .gdas.225564.2016081200.nc
> >>> DEBUG 2:
> >>> DEBUG 2:
------------------------------------------------------------
> >>> --------------------
> >>> DEBUG 2:
> >>> DEBUG 2: Reading data for T2(*,*,0).
> >>> WARNING:
> >>> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
> >> double
> >>> &) const -> star found in bad slot
> >>> WARNING:
> >>> ERROR :
> >>> ERROR : PinterpFile::valid_time(int) const -> range check error
> >>> ERROR :
> >>>
> >>>
> >>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
> >>> float T2(Time, south_north, west_east) ;
> >>> T2:FieldType = 104 ;
> >>> T2:MemoryOrder = "XY " ;
> >>> T2:description = "TEMP at 2 M" ;
> >>> T2:units = "K" ;
> >>> T2:stagger = "" ;
> >>> T2:coordinates = "XLONG XLAT XTIME" ;
> >>> T2:missing_value = 1.e+36f ;
> >>>
> >>> I am not sure if the issue is that P_Interp is not properly
extracting
> >>> this information, or If I just need to change my
PointStatConfig1 file.
> >>>
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> Matthew G. Dawson, Capt, USAF
> >>> AFIT Student, Civilian Institution Program
> >>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
> >> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
> >>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>
> >>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
> tcram at ucar.edu> <mailto:
> >> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
> >>>
> >>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:
> tcram at ucar.edu>>>> wrote:
> >>>
> >>>
> >>> Hi Matthew,
> >>>
> >>> I recommend contacting MET support (cc'd here). It's possible
you
> >>>
> >>> should be using the PrepBUFR data instead of the NetCDF data in
MET,
> but
> >>> having no experience using MET, I am merely speculating on this.
MET
> >>> support should be able to help you out.
> >>>
> >>>
> >>> Good luck,
> >>> - Tom
> >>>
> >>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
> <mailto:dawsonmattg at gmail.com>
> >> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>
> >>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:
> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
> >>>
> >>> Hey Thomas
> >>>
> >>> I was able to get the data download with no issues, however I
have been
> >>>
> >>> having issues with actually using that data in MET. I am trying
to
> >> compare
> >>> it to some WRF output (used P-Interp to convert into a MET
readable
> >>> format), but the PointStatConfig file keeps having issues (I’m
not
> sure I
> >>> filled it out correctly). Anyways I was wondering if you, or
anyone
> >>> happened to know of an online resource, or even someone who had
a
> >>> configuration set up for comparing data against WRF data so I
can
> compare
> >>> what I have against there config files and hopefully figure out
where I
> >> am
> >>> going wrong. I’ve been looking through the MET user guide but
haven’t
> >> found
> >>> a solution yet. Thanks!
> >>>
> >>>
> >>> Matthew G. Dawson, Capt, USAF
> >>> AFIT Student, Civilian Institution Program
> >>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
> >> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
> <mailto:
> >> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
> >>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
> <tel:%28904%29-333-5427>
> >> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
> >>> <%28904%29-333-5427>>
> >>>
> >>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
> >> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu>>
> >>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu>>>>
> >>>
> >>> wrote:
> >>>
> >>>
> >>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
> >>>
> >>> Observations has completed.
> >>>
> >>> Please login to the NCAR RDA server at http://rda.ucar.edu <
> http://rda.ucar.edu/> <
> >> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
> >>>
> >>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
> http://rda.ucar.edu/>>>, then download your files
> >> from the
> >>>
> >>> following URL:
> >>>
> >>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
> <http://rda.ucar.edu/#dsrqst/D>
> >> AWSON225564/> <
> >>>
> >>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
> <http://rda.ucar.edu/#dsrqst/D>
> >> AWSON225564/>>
> >>>
> >>>
> >>> Request ID: DAWSON225564
> >>>
> >>> Request Detail:
> >>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>> NCEP Verification Regions : SEC
> >>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> >>>
> >>> PRMSL
> >>>
> >>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> >>>
> >>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>>
> >>> Quality Mark Threshold : 9
> >>> File Compression : gz
> >>> Data Output Format : NETCDF
> >>>
> >>>
> >>> The "rda-request-manager" command line tool provides an
additional
> >>>
> >>> option for users to download
> >>>
> >>> request output files on unix based systems. The "rda-request-
manager"
> >>>
> >>> tool can be accessed at:
> >>>
> >>>
> >>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
> >> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
> >>>
> >>> The data provided in your data request are a subset of the NCAR
RDA
> >>>
> >>> dataset ds337.0 --
> >>>
> >>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
> >>>
> >>> format), May 1997 - Continuing'. Please see
> >> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/> <
> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
> >>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
> http://rda.ucar.edu/datasets/ds337.0/> <
> >> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
> ds337.0/>>> for more information.
> >>>
> >>>
> >>> Your data will remain on our system for 5 days. If this is not
> >>>
> >>> sufficient time for you to retrieve
> >>>
> >>> your data, please let me know as soon as possible, so that I can
> >>>
> >>> prevent the data files from being
> >>>
> >>> purged too soon.
> >>>
> >>> If you have any questions related to this data request, please
let me
> >>>
> >>> know by replying to this
> >>>
> >>> email.
> >>>
> >>> Sincerely,
> >>>
> >>> Thomas Cram
> >>> NCAR/CISL/Data Support Section
> >>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
> <tel:%28303%29-497-1217>
> >> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
> >>> <%28303%29-497-1217>>
> >>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
> >>> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/
> <http://rda.ucar.edu/>> <http://rda.ucar.edu/ <http://rda.ucar.edu/>
<
> >> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Thomas Cram
> >>> NCAR / CISL / DSS
> >>> tel: +1-303-497-1217 <(303)%20497-1217>
> >>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
> >>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/ <
> http://rda.ucar.edu/>> <http://rda.ucar.edu/ <http://rda.ucar.edu/>
<
> >> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>
> >>>
> >>> Matthew G. Dawson, Capt, USAF
> >>> AFIT Student, Civilian Institution Program
> >>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
> >>> Cell: (904)-333-5427 <(904)%20333-5427>
>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Thu Feb 23 18:15:02 2017
John,
Awesome! So a technical question for you. I download some archived
MADIS data over Florida link (https://madis-
data.ncep.noaa.gov/madisPublic1/data/archive/2016/08/12/LDAD/mesonet/netCDF/)
. I was looking through the Met manual but it didn’t give me too much
information on the madis2nc converter program. Since I am am only
interested in the surface data (wind, temp, td, total preccip), would
I want do "-lvl_dim 0” ? also for the type str since the MADIS has
a bunch of different types of data but I am primary interested in the
meter & mesonet data, should I put “- type meter mesonet”, I wasn’t
sure if this was simply for a naming convection or if specifying the
type actually directed the program to look for specific files formats.
Also I’m not sure if I can specify I only want temperature, wind
direction, wind speed, precip data but that easily possible it would
be nice to save some space! I think those are the main things I am
concerned about but if there is something else you think I am missing
please let me know, thanks!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 22, 2017, at 11:32 AM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>
> Matthew,
>
> Sounds like an interesting project. Yes, the MET tools can be used
to
> perform the individual comparisons, but there remains a lot of work
to be
> done to script up the calls to them in the right order to accomplish
your
> task.
>
> I've done a lot of that type of work using PERL and shell scripts
(mostly
> ksh). I think we've gotten to the point in the development of the
MET
> software, that setting up the controlling scripts is the biggest
hurdle to
> using the software. In the last few months we've begun work on a
system
> we're calling MET+ which is a set of python wrapper scripts for the
MET
> tools to "automate" this scripting as much as possible. This work
is
> driven mainly by the needs of the operational modelling community.
But
> hopefully, a user, like yourself, would be able to set up a
configuration
> script which the python wrapper scripts use to call the MET tools in
the
> right order. But that's down the road. For now, you're stuck doing
it
> yourself using whatever scripting language you prefer.
>
> It sounds like you're interested in continuous statistics (ME, RMSE)
for
> surface variables and categorical stats (MODE objects and maybe ETS)
for
> precip. You'd ultimately use Point-Stat for surface point-based
> verification, Grid-Stat for categorical verification of precip, and
MODE
> for an object-based evaluation of precip. While you could run
Point-Stat
> for every 15 minute output, that may be overkill. I'd suggest doing
it
> hourly, unless there's a good reason to do it more often.
>
> You run Point-Stat, Grid-Stat, and MODE once for each combination of
model
> and output time. So you'll do many runs of those tools. From
Point-Stat,
> you want the CNT line type (continuous stats) as well as the SL1L2
and
> VL1L2 line types (scalar and vector parial sums) which can be
aggregated
> later. You could consider dumping the individual matched pair
values (MPR
> line type) but that can get to be a lot of data very quickly. From
> Grid-Stat, you want the CTC and CTS line type (contingency table
counts and
> statistics). Prior to running Point-Stat, you'd run PB2NC to pre-
process
> PREPBUFR point observations. And prior to running Grid-Stat or
MODE you
> may need to run pcp_combine if you need to change the accumulation
> intervals of your precip data. Lastly, the STAT-Analysis tool is
used to
> read the output of Point-Stat and Grid-Stat and accumulate
statistics over
> the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
> lines from each run and derive aggregated statistics. Similarly, it
can be
> used to aggregate CTC lines from each run and derive aggregated
categorical
> statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
(FBIAS).
>
> So lots of little steps to accomplish, but once you get the calls
scripted
> up, hopefully it'll go smoothly for you.
>
> Hope that helps.
>
> Thanks,
> John
>
> On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>>
>> John,
>>
>> Thanks for all the good info! Heres a little scoop on what I am
trying to
>> accomplish if your interested, if not I have answers to your
questions
>> starting at **********
>>
>> You might be familiar with the AMU (Applied Meteorology Unit
>> https://science.ksc.nasa.gov/amu/history.html <
>> https://science.ksc.nasa.gov/amu/history.html>) that is down in
cape
>> canaveral. They were tasked with setting up a mesoscale model to
improve
>> operational forecast, and ran a few different verification
statistics (ME,
>> RMSE, MODE) on a number of different configurations your interested
here a
>> link to their first Technical Report (Watson_2013-https://ntrs.
>> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
>> jsp?R=20150000384> ). Several changes have occurred over the past
few
>> years included triple nested model as opposed to double nested,
smaller
>> grid space, and a myriad of additional observations/assimilated
data sets
>> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
>> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
>> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
>> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
>>
>> Talking with the head civilian down their, lightning delays are
their
>> primary problem, as well as forecasting convection in SE flow. So
after
>> reading up on their configuration it seemed like using a more up to
date
>> Microphysical model would produce better precipitation statistics
and a
>> better overall approximation of developing convection. So I used 3
>> different microphysics schemes to create 12 different model runs,
which
>> show some reasonable difference when plotting rain totals ect.
>>
>> ************
>> So with the 12 different models I am trying to create a “scorecard”
to
>> show which ones more accurately predicted the surface
precipitation, wind
>> speed, direction, T, Td.
>>
>> The week of model runs were purposely selected over a period
predominantly
>> SE flow (august) which they have trouble forecasting for. This is
somewhat
>> of a sub-regime in their overall summertime regime, but since most
>> convection is characterized by mesoscale process (sea-breeze,
river-breeze)
>> it could be extended for the entire summer months. The model was
PRIMARY
>> developed to help summertime forecast as lightning delays cost them
lots of
>> $$$, so I’m not even sure if they rely on this model, as opposed to
some of
>> the national centers, during other seasons.
>>
>> Since the prior work from the above papers used ME, RMSE in the
point stat
>> tool and MODE for precip I want to try use the same techniques.
>>
>> I guess my real question would be how I should go about setting
everything
>> up, coding.
>>
>> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
>> (precip) values for each day and for the total week. Since my wrf
outfiles
>> are in 15 min intervals, over 24 hours I’m not sure how to specify
in point
>> stat how to read in all these files and produce one RMSE and ME
value for
>> the day, or produce them for each time and them calculate the total
for the
>> day. I’m not sure if I need to somehow mesh all my wrfout files
into one
>> file and then have point stat use that or if there is a simpler
way.
>>
>>
>> Matthew G. Dawson, Capt, USAF
>> AFIT Student, Civilian Institution Program
>> Email: Dawsonmattg at gmail.com
>> Cell: (904)-333-5427
>>
>>> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>>
>>> Matthew,
>>>
>>> Great, I'm glad you were able to get it up and running!
>>>
>>> There's no need to acknowledge me directly, but I'd appreciate you
>>> acknowledging the MET software package. The more advertising we
can get
>>> for future funding, the better!
>>>
>>> As for your choice of verification datasets, that's usually
limited by
>> your
>>> domain, the timing of your model output, and the actual
verification
>>> questions you're trying to answer. With output from 12 different
models,
>>> what are you actually trying to assess? Is it just a scorecard to
see
>>> which model verifies better overall? Or do you have more specific
>>> questions? With only one week of data to compare, you can do an
>> objective
>>> comparison... but will your results hold up during the other 3
seasons?
>> Or
>>> during other weather regimes? So I'd be hesitant in using only
one week
>> of
>>> data to make strong claims about overall performance.
>>>
>>> With data every 15 minutes, I believe that the surface data shows
up
>> pretty
>>> in PREPBUFR pretty regularly. So you could do surface
verification up to
>>> every 15 minutes if you'd like. While there are a very small
number of
>>> soundings in PREPBUFR files at off-hours, we generally only verify
>>> upper-air at 00Z and 12Z.
>>>
>>> For choice of precipitation analysis... I'd suggest reading about
>> StageII,
>>> StageIV, CCPA, and MRMS. We've used all of them on different
projects
>>> within the DTC. MRMS is probably the one being most actively
worked on
>>> right now. Depending on what questions you're asking, you could
also
>>> compare against URMA which is a gridded CONUS analysis product.
>>>
>>> Let me warn you that I'm a software engineer, not a statistician
or
>>> atmospheric scientist. But we do have both of them on the MET
team. So
>> if
>>> you have specific questions in those areas, I could route them to
the
>> right
>>> person.
>>>
>>> Hope that helps.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> via RT <
>>> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>>>>
>>>> Hey John,
>>>>
>>>> Sorry for the late reply, but your suggestion worked! I
also
>>>> figured out I was referencing the wrong file time which of course
would
>>>> come back with no results.
>>>>
>>>> I was curious though how you would suggest tackling my
“project".
>>>> I have 12 different model outputs (the same domain) over the same
week
>> that
>>>> I want to try verify. The model output occurs at 15 min
intervals, and
>> I am
>>>> primary interested in precipitation skill scores (would like to
use the
>>>> MODE tool), but the temperature, Td, wind speed and direction
will also
>> be
>>>> useful. I was planing on using the MODE tool to evaluate the SFC
precip
>> to
>>>> stage II radar data unless you would recommend another way. Also
please
>> let
>>>> me know if you would like me to add you in my acknowledgement
section
>> for
>>>> help with this tool kit, thanks!
>>>>
>>>> Matthew G. Dawson, Capt, USAF
>>>> AFIT Student, Civilian Institution Program
>>>> Email: Dawsonmattg at gmail.com
>>>> Cell: (904)-333-5427
>>>>
>>>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>>
>>>>> According to our records, your request has been resolved. If you
have
>> any
>>>>> further questions or concerns, please respond to this message.
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
>> met_help at ucar.edu
>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>>>
>>>> Matthew,
>>>>
>>>> The verification of surface variables is done in a pretty
simplistic
>> way by
>>>> specifying the message type.
>>>>
>>>> The ADPSFC and SFCSHP message types are assumed to exist at the
surface
>> and
>>>> are used to verifying "surface" variables such as 2m temperature
and
>> 10-m
>>>> winds. And ONLYSF is a short-cut for combining land-based ADPSFC
and
>>>> water-based SFCSHP observations together. Your Point-Stat config
file
>>>> should look something like this:
>>>>
>>>> fcst = {
>>>> field = [
>>>> {
>>>> name = "T2";
>>>> level = [ "(*,*,0)" ];
>>>> cat_thresh = [ <=273, >273 ];
>>>> }
>>>> ];
>>>> }
>>>>
>>>> obs = {
>>>> message_type = [ "ADPSFC" ];
>>>> sid_exc = [];
>>>>
>>>> field = [
>>>> {
>>>> name = "TMP";
>>>> level = [ "Z2" ];
>>>> cat_thresh = [ <=273, >273 ];
>>>> }
>>>> ];
>>>> }
>>>>
>>>> Does that produce any matched pairs? I don't see the source of
the
>>>> PREPBUFR observation data you're using, but if you're using GDAS,
please
>>>> read the NOTE at the bottom of this page about the quality marker
that's
>>>> assigned to surface observations:
>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>> http://www.dtcenter.org/met/users/downloads/observation_data.php> <
>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>> http://www.dtcenter.org/met/users/downloads/observation_data.php>>
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>> wrote:
>>>>
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>
>>>>> John,
>>>>>
>>>>> Thanks for the reply! I originally wanted to use UPP, but the
cluster I
>>>> ran
>>>>> my WRF models on didn’t have much space (very fast though) so I
had to
>>>>> offload all my data to another cluster my professor uses which
isn’t
>> very
>>>>> fast but has plenty of space. Since UPP has to have a path to my
WRF
>>>> build
>>>>> (excerpt below), I decided it was not feasible.
>>>>>
>>>>> "Overview of the scripts to run the UPP Note: It is recommended
that
>> the
>>>>> user refer to the run_unipost* scripts in the script/ while
reading
>> this
>>>>> overview.
>>>>> 1. Set up variables:
>>>>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
>>>>> DOMAINPATH: directory where UPP will be run from
>>>>> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
>>>>> used during the installation with the configure script
>>>>> UNI_POST_HOME: path to your UPPV2.1 build
>>>>> POSTEXEC: path to your UPPV2.1 executables”
>>>>>
>>>>> As for the winds, my WRF output does supply 10 meter winds,
which I
>> would
>>>>> assume P_Interp would just put at the level (0,*,*), so in the
case
>>>>> shouldn't I be able to verify winds as well?
>>>>>
>>>>> Anyways I tried your fix and while it does run I'm not actually
getting
>>>> any
>>>>> values. I'm fairly certain its because I specified the Level for
the
>> obs
>>>>> at, "P1000". I'm not sure how to specify the level as the
"surface" or
>> 10
>>>>> meters though.
>>>>>
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Reading data for T2(0,*,*).
>>>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
>> levels.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Searching 41979 observations from 6956 messages.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
>>>>> DEBUG 1: Output file:
>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
>>>>> DEBUG 1: Output file:
>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>>>>>
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>
>>>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
>> met_help at ucar.edu <mailto:met_help at ucar.edu>
>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
>>>>> wrote:
>>>>>
>>>>> Matthew,
>>>>>
>>>>> I see that you have some questions about running the Point-Stat
tool.
>>>>>
>>>>> Regarding post-processing, I'd suggest switching from the
pinterp
>> utility
>>>>> to using the Unified Post-Processor (UPP). It writes output in
GRIB
>>>> which
>>>>> MET can easily handle. Why pinterp output could work fine for
precip,
>>>>> temperature, and dewpoint, MET won't be able to process the
winds since
>>>>> they're defined on the staggered dimension. I realize that
running
>> UPP,
>>>>> yet another tool to compile and script up, can be a hassle. But
I
>> think
>>>>> it'll be less work in the long run.
>>>>>
>>>>> But as for your specific error from Point-Stat, I suspect
that'll be
>> easy
>>>>> to fix. In your Point-Stat config file, try using:
>>>>> name = "T2";
>>>>> level = [ "(0,*,*)" ];
>>>>>
>>>>> I often like plotting the data first:
>>>>> met-5.2/bin/plot_data_plane \
>>>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
>>>>> d01_2016-08-12_12:00:00_PLEV
>>>>> \
>>>>> T2.ps \
>>>>> 'name="T2"; level="(0,*,*)";'
>>>>>
>>>>> Hopefully that'll create a PostScript plot of your data.
>>>>>
>>>>> Thanks,
>>>>> John Halley Gotway
>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>
>>>>>
>>>>>
>>>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>> wrote:
>>>>>
>>>>>
>>>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
>>>>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>> Queue: met_help
>>>>> Subject: Point Stat help
>>>>> Owner: Nobody
>>>>> Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>
>>>>>
>>>>> Hello MET help,
>>>>>
>>>>> I’m going to go ahead and apologize for all the information
in
>>>>> this email, but hopefully it will help you better diagnose what
the
>> best
>>>>> way for me to move forward is. As part of my research I
generated 12
>>>>> different WRF runs over the same week using the same I.C.s and
B.C.s,
>> and
>>>>> am currently in the process of comparing them against real world
>>>>> observations to see which config worked the best. I am primary
>> concerned
>>>>> with comparing precip, surface temp/dewpoint, and surface winds.
>>>>>
>>>>> The first tool I have tried to use has been the point stat
tool. I
>>>>> am using your met-5.2_bugfix package and did not find any errors
>>>>> while/after compiling and made sure the test files, like
>>>>> test_point_stat.sh, all work. The data I am using is as follows:
>>>>>
>>>>>
>>>>> Instead of downloading prepbufer files and
converting them
>>>>> with the PB2NC tool, I just used the UCAR site to do it for me
(
>>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
>>>> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
>> http://rda.ucar.edu/datasets/>
>>>> ds337.0/index.html#forms/337_subset.php?_da=y>
>>>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
>>>>> subset.php?_da=y>)
>>>>> Request Detail:
>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>> NCEP Verification Regions : SEC
>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>> PRMSL
>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>> Quality Mark Threshold : 9
>>>>> File Compression : gz
>>>>> Data Output Format : NETCDF
>>>>>
>>>>>
>>>>>
>>>>> To convert my WRF data into a readable format I used
P_Interp. I
>>>>> am now realizing this might not be the best way forward, but
seemed the
>>>>> easiest to set up as I had to offload all my model output to a
>> different
>>>>> cluster that I did not configure WRF on. I have been a bit
confused as
>>>>> P_Interp says it can unstager data to pressure levels, but on
your
>>>> website
>>>>> it says that P_Interp cannot onstager data (at least for use
with MODE
>>>> and
>>>>> other tools). Either way do you think I should try use a
different
>>>>> pre-processing software to unpack my WRF data or will P_Interp
be
>>>>> sufficient to compare precip, surface temp/dewpoint and winds?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> When I run my file PointStat.sh using the attached
>>>>> PointStatConfig1 file, I get the following data error message:
>>>>>
>>>>> *** Running Point-Stat on prepbuffer files ***
>>>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
>>>>> bugfix/share/met/config/PointStatConfig_default
>>>>> DEBUG 1: User Config File: config/PointStatConfig
>>>>> GSL_RNG_TYPE=mt19937
>>>>> GSL_RNG_SEED=1
>>>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
>>>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
>>>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
>>>>> .gdas.225564.2016081200.nc
>>>>> DEBUG 2:
>>>>> DEBUG 2:
------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Reading data for T2(*,*,0).
>>>>> WARNING:
>>>>> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
>>>> double
>>>>> &) const -> star found in bad slot
>>>>> WARNING:
>>>>> ERROR :
>>>>> ERROR : PinterpFile::valid_time(int) const -> range check error
>>>>> ERROR :
>>>>>
>>>>>
>>>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
>>>>> float T2(Time, south_north, west_east) ;
>>>>> T2:FieldType = 104 ;
>>>>> T2:MemoryOrder = "XY " ;
>>>>> T2:description = "TEMP at 2 M" ;
>>>>> T2:units = "K" ;
>>>>> T2:stagger = "" ;
>>>>> T2:coordinates = "XLONG XLAT XTIME" ;
>>>>> T2:missing_value = 1.e+36f ;
>>>>>
>>>>> I am not sure if the issue is that P_Interp is not properly
extracting
>>>>> this information, or If I just need to change my
PointStatConfig1 file.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
>>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>
>>>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
>> tcram at ucar.edu> <mailto:
>>>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
>>>>>
>>>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:
>> tcram at ucar.edu>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Matthew,
>>>>>
>>>>> I recommend contacting MET support (cc'd here). It's possible
you
>>>>>
>>>>> should be using the PrepBUFR data instead of the NetCDF data in
MET,
>> but
>>>>> having no experience using MET, I am merely speculating on this.
MET
>>>>> support should be able to help you out.
>>>>>
>>>>>
>>>>> Good luck,
>>>>> - Tom
>>>>>
>>>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
>> <mailto:dawsonmattg at gmail.com>
>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>>
>>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
>>>>>
>>>>> Hey Thomas
>>>>>
>>>>> I was able to get the data download with no issues, however I
have been
>>>>>
>>>>> having issues with actually using that data in MET. I am trying
to
>>>> compare
>>>>> it to some WRF output (used P-Interp to convert into a MET
readable
>>>>> format), but the PointStatConfig file keeps having issues (I’m
not
>> sure I
>>>>> filled it out correctly). Anyways I was wondering if you, or
anyone
>>>>> happened to know of an online resource, or even someone who had
a
>>>>> configuration set up for comparing data against WRF data so I
can
>> compare
>>>>> what I have against there config files and hopefully figure out
where I
>>>> am
>>>>> going wrong. I’ve been looking through the MET user guide but
haven’t
>>>> found
>>>>> a solution yet. Thanks!
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
>> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
>> <mailto:
>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
>> <tel:%28904%29-333-5427>
>>>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
>>>>> <%28904%29-333-5427>>
>>>>>
>>>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>>
>>>>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>>>>>
>>>>> Observations has completed.
>>>>>
>>>>> Please login to the NCAR RDA server at http://rda.ucar.edu <
>> http://rda.ucar.edu/> <
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
>>>>>
>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
>> http://rda.ucar.edu/>>>, then download your files
>>>> from the
>>>>>
>>>>> following URL:
>>>>>
>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>> <http://rda.ucar.edu/#dsrqst/D>
>>>> AWSON225564/> <
>>>>>
>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>> <http://rda.ucar.edu/#dsrqst/D>
>>>> AWSON225564/>>
>>>>>
>>>>>
>>>>> Request ID: DAWSON225564
>>>>>
>>>>> Request Detail:
>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>> NCEP Verification Regions : SEC
>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>>>>>
>>>>> PRMSL
>>>>>
>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>>
>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>>
>>>>> Quality Mark Threshold : 9
>>>>> File Compression : gz
>>>>> Data Output Format : NETCDF
>>>>>
>>>>>
>>>>> The "rda-request-manager" command line tool provides an
additional
>>>>>
>>>>> option for users to download
>>>>>
>>>>> request output files on unix based systems. The "rda-request-
manager"
>>>>>
>>>>> tool can be accessed at:
>>>>>
>>>>>
>>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
>>>>>
>>>>> The data provided in your data request are a subset of the NCAR
RDA
>>>>>
>>>>> dataset ds337.0 --
>>>>>
>>>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>>>>>
>>>>> format), May 1997 - Continuing'. Please see
>>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/> <
>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
>>>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
>> http://rda.ucar.edu/datasets/ds337.0/> <
>>>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
>> ds337.0/>>> for more information.
>>>>>
>>>>>
>>>>> Your data will remain on our system for 5 days. If this is not
>>>>>
>>>>> sufficient time for you to retrieve
>>>>>
>>>>> your data, please let me know as soon as possible, so that I can
>>>>>
>>>>> prevent the data files from being
>>>>>
>>>>> purged too soon.
>>>>>
>>>>> If you have any questions related to this data request, please
let me
>>>>>
>>>>> know by replying to this
>>>>>
>>>>> email.
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Thomas Cram
>>>>> NCAR/CISL/Data Support Section
>>>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
>> <tel:%28303%29-497-1217>
>>>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
>>>>> <%28303%29-497-1217>>
>>>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/
>> <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thomas Cram
>>>>> NCAR / CISL / DSS
>>>>> tel: +1-303-497-1217 <(303)%20497-1217>
>>>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/ <
>> http://rda.ucar.edu/>> <http://rda.ucar.edu/ <http://rda.ucar.edu/>
<
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>
>>
>>
>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Fri Feb 24 16:01:16 2017
Matthew,
Those are all very good questions.
Let me start with the easy one first. There are multiple types of
MADIS
data files and each flavor is, unfortunately, formatted a little
differently. The "-type" command line argument is required to tell
the
tool how to interpret the data. So when you're processing mesonet
data,
use "-type mesonet", and madis2nc will parse the values correctly.
The
list of supported types is included in the usage statement for the
tool
(just type "madis2nc" with no arguments to see the usage).
Another point to make is that madis2nc dumps out a *lot* of very
detailed
information at verbosity level 3. So passing "-v 3" to the tool will
dump
out info about each location/observation value processed.
Another question is, can you filter the observations retained by
variable.
While that would be a pretty straight-forward enhancement for this
tool,
the answer is no, you can't. But you have the source code... if
there's a
very good reason to do so, you could comment out the lines which
process
the observation types you'd like to skip. But you can filter
spatially
using the "-mask_grid" or "-mask_poly" option.
Lastly, the -lvl_dim option only applies to RAOB type metars. The
METAR
and MESONET datasets don't have level information by which to filter.
Looking closely, I see that the ACARS and PROFILER types *do* have
level
information, but the -lvl_dim options logic is not being applied to
them.
We should probably revisit that.
Hope that helps clarify.
John
On Thu, Feb 23, 2017 at 6:15 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> John,
>
> Awesome! So a technical question for you. I download some
> archived MADIS data over Florida link (https://madis-data.ncep.noaa.
> gov/madisPublic1/data/archive/2016/08/12/LDAD/mesonet/netCDF/) . I
was
> looking through the Met manual but it didn’t give me too much
information
> on the madis2nc converter program. Since I am am only interested in
the
> surface data (wind, temp, td, total preccip), would I want do "-
lvl_dim
> 0” ? also for the type str since the MADIS has a bunch of different
types
> of data but I am primary interested in the meter & mesonet data,
should I
> put “- type meter mesonet”, I wasn’t sure if this was simply for a
naming
> convection or if specifying the type actually directed the program
to look
> for specific files formats. Also I’m not sure if I can specify I
only want
> temperature, wind direction, wind speed, precip data but that easily
> possible it would be nice to save some space! I think those are the
main
> things I am concerned about but if there !
> is something else you think I am missing please let me know,
thanks!
>
>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
> > On Feb 22, 2017, at 11:32 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
> >
> > Matthew,
> >
> > Sounds like an interesting project. Yes, the MET tools can be
used to
> > perform the individual comparisons, but there remains a lot of
work to be
> > done to script up the calls to them in the right order to
accomplish your
> > task.
> >
> > I've done a lot of that type of work using PERL and shell scripts
(mostly
> > ksh). I think we've gotten to the point in the development of the
MET
> > software, that setting up the controlling scripts is the biggest
hurdle
> to
> > using the software. In the last few months we've begun work on a
system
> > we're calling MET+ which is a set of python wrapper scripts for
the MET
> > tools to "automate" this scripting as much as possible. This work
is
> > driven mainly by the needs of the operational modelling community.
But
> > hopefully, a user, like yourself, would be able to set up a
configuration
> > script which the python wrapper scripts use to call the MET tools
in the
> > right order. But that's down the road. For now, you're stuck
doing it
> > yourself using whatever scripting language you prefer.
> >
> > It sounds like you're interested in continuous statistics (ME,
RMSE) for
> > surface variables and categorical stats (MODE objects and maybe
ETS) for
> > precip. You'd ultimately use Point-Stat for surface point-based
> > verification, Grid-Stat for categorical verification of precip,
and MODE
> > for an object-based evaluation of precip. While you could run
Point-Stat
> > for every 15 minute output, that may be overkill. I'd suggest
doing it
> > hourly, unless there's a good reason to do it more often.
> >
> > You run Point-Stat, Grid-Stat, and MODE once for each combination
of
> model
> > and output time. So you'll do many runs of those tools. From
> Point-Stat,
> > you want the CNT line type (continuous stats) as well as the SL1L2
and
> > VL1L2 line types (scalar and vector parial sums) which can be
aggregated
> > later. You could consider dumping the individual matched pair
values
> (MPR
> > line type) but that can get to be a lot of data very quickly.
From
> > Grid-Stat, you want the CTC and CTS line type (contingency table
counts
> and
> > statistics). Prior to running Point-Stat, you'd run PB2NC to pre-
process
> > PREPBUFR point observations. And prior to running Grid-Stat or
MODE you
> > may need to run pcp_combine if you need to change the accumulation
> > intervals of your precip data. Lastly, the STAT-Analysis tool is
used to
> > read the output of Point-Stat and Grid-Stat and accumulate
statistics
> over
> > the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
> > lines from each run and derive aggregated statistics. Similarly,
it can
> be
> > used to aggregate CTC lines from each run and derive aggregated
> categorical
> > statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
> (FBIAS).
> >
> > So lots of little steps to accomplish, but once you get the calls
> scripted
> > up, hopefully it'll go smoothly for you.
> >
> > Hope that helps.
> >
> > Thanks,
> > John
> >
> > On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
> > met_help at ucar.edu> wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
> >>
> >> John,
> >>
> >> Thanks for all the good info! Heres a little scoop on what I am
trying
> to
> >> accomplish if your interested, if not I have answers to your
questions
> >> starting at **********
> >>
> >> You might be familiar with the AMU (Applied Meteorology Unit
> >> https://science.ksc.nasa.gov/amu/history.html <
> >> https://science.ksc.nasa.gov/amu/history.html>) that is down in
cape
> >> canaveral. They were tasked with setting up a mesoscale model to
improve
> >> operational forecast, and ran a few different verification
statistics
> (ME,
> >> RMSE, MODE) on a number of different configurations your
interested
> here a
> >> link to their first Technical Report (Watson_2013-https://ntrs.
> >> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
> >> jsp?R=20150000384> ). Several changes have occurred over the past
few
> >> years included triple nested model as opposed to double nested,
smaller
> >> grid space, and a myriad of additional observations/assimilated
data
> sets
> >> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
> >> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
> >> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
> >> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
> >>
> >> Talking with the head civilian down their, lightning delays are
their
> >> primary problem, as well as forecasting convection in SE flow. So
after
> >> reading up on their configuration it seemed like using a more up
to date
> >> Microphysical model would produce better precipitation statistics
and a
> >> better overall approximation of developing convection. So I used
3
> >> different microphysics schemes to create 12 different model runs,
which
> >> show some reasonable difference when plotting rain totals ect.
> >>
> >> ************
> >> So with the 12 different models I am trying to create a
“scorecard” to
> >> show which ones more accurately predicted the surface
precipitation,
> wind
> >> speed, direction, T, Td.
> >>
> >> The week of model runs were purposely selected over a period
> predominantly
> >> SE flow (august) which they have trouble forecasting for. This is
> somewhat
> >> of a sub-regime in their overall summertime regime, but since
most
> >> convection is characterized by mesoscale process (sea-breeze,
> river-breeze)
> >> it could be extended for the entire summer months. The model was
PRIMARY
> >> developed to help summertime forecast as lightning delays cost
them
> lots of
> >> $$$, so I’m not even sure if they rely on this model, as opposed
to
> some of
> >> the national centers, during other seasons.
> >>
> >> Since the prior work from the above papers used ME, RMSE in the
point
> stat
> >> tool and MODE for precip I want to try use the same techniques.
> >>
> >> I guess my real question would be how I should go about setting
> everything
> >> up, coding.
> >>
> >> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
> >> (precip) values for each day and for the total week. Since my wrf
> outfiles
> >> are in 15 min intervals, over 24 hours I’m not sure how to
specify in
> point
> >> stat how to read in all these files and produce one RMSE and ME
value
> for
> >> the day, or produce them for each time and them calculate the
total for
> the
> >> day. I’m not sure if I need to somehow mesh all my wrfout files
into one
> >> file and then have point stat use that or if there is a simpler
way.
> >>
> >>
> >> Matthew G. Dawson, Capt, USAF
> >> AFIT Student, Civilian Institution Program
> >> Email: Dawsonmattg at gmail.com
> >> Cell: (904)-333-5427
> >>
> >>> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu> wrote:
> >>>
> >>> Matthew,
> >>>
> >>> Great, I'm glad you were able to get it up and running!
> >>>
> >>> There's no need to acknowledge me directly, but I'd appreciate
you
> >>> acknowledging the MET software package. The more advertising we
can
> get
> >>> for future funding, the better!
> >>>
> >>> As for your choice of verification datasets, that's usually
limited by
> >> your
> >>> domain, the timing of your model output, and the actual
verification
> >>> questions you're trying to answer. With output from 12
different
> models,
> >>> what are you actually trying to assess? Is it just a scorecard
to see
> >>> which model verifies better overall? Or do you have more
specific
> >>> questions? With only one week of data to compare, you can do
an
> >> objective
> >>> comparison... but will your results hold up during the other 3
seasons?
> >> Or
> >>> during other weather regimes? So I'd be hesitant in using only
one
> week
> >> of
> >>> data to make strong claims about overall performance.
> >>>
> >>> With data every 15 minutes, I believe that the surface data
shows up
> >> pretty
> >>> in PREPBUFR pretty regularly. So you could do surface
verification up
> to
> >>> every 15 minutes if you'd like. While there are a very small
number of
> >>> soundings in PREPBUFR files at off-hours, we generally only
verify
> >>> upper-air at 00Z and 12Z.
> >>>
> >>> For choice of precipitation analysis... I'd suggest reading
about
> >> StageII,
> >>> StageIV, CCPA, and MRMS. We've used all of them on different
projects
> >>> within the DTC. MRMS is probably the one being most actively
worked on
> >>> right now. Depending on what questions you're asking, you could
also
> >>> compare against URMA which is a gridded CONUS analysis product.
> >>>
> >>> Let me warn you that I'm a software engineer, not a statistician
or
> >>> atmospheric scientist. But we do have both of them on the MET
team.
> So
> >> if
> >>> you have specific questions in those areas, I could route them
to the
> >> right
> >>> person.
> >>>
> >>> Hope that helps.
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>>
> >>>
> >>> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com <mailto:
> >> dawsonmattg at gmail.com> via RT <
> >>> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >>>
> >>>>
> >>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
> >>>>
> >>>> Hey John,
> >>>>
> >>>> Sorry for the late reply, but your suggestion worked! I
also
> >>>> figured out I was referencing the wrong file time which of
course
> would
> >>>> come back with no results.
> >>>>
> >>>> I was curious though how you would suggest tackling my
> “project".
> >>>> I have 12 different model outputs (the same domain) over the
same week
> >> that
> >>>> I want to try verify. The model output occurs at 15 min
intervals, and
> >> I am
> >>>> primary interested in precipitation skill scores (would like to
use
> the
> >>>> MODE tool), but the temperature, Td, wind speed and direction
will
> also
> >> be
> >>>> useful. I was planing on using the MODE tool to evaluate the
SFC
> precip
> >> to
> >>>> stage II radar data unless you would recommend another way.
Also
> please
> >> let
> >>>> me know if you would like me to add you in my acknowledgement
section
> >> for
> >>>> help with this tool kit, thanks!
> >>>>
> >>>> Matthew G. Dawson, Capt, USAF
> >>>> AFIT Student, Civilian Institution Program
> >>>> Email: Dawsonmattg at gmail.com
> >>>> Cell: (904)-333-5427
> >>>>
> >>>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
> >>>> met_help at ucar.edu> wrote:
> >>>>>
> >>>>> According to our records, your request has been resolved. If
you have
> >> any
> >>>>> further questions or concerns, please respond to this message.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu
> >>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
> >>>>
> >>>> Matthew,
> >>>>
> >>>> The verification of surface variables is done in a pretty
simplistic
> >> way by
> >>>> specifying the message type.
> >>>>
> >>>> The ADPSFC and SFCSHP message types are assumed to exist at the
> surface
> >> and
> >>>> are used to verifying "surface" variables such as 2m
temperature and
> >> 10-m
> >>>> winds. And ONLYSF is a short-cut for combining land-based
ADPSFC and
> >>>> water-based SFCSHP observations together. Your Point-Stat
config file
> >>>> should look something like this:
> >>>>
> >>>> fcst = {
> >>>> field = [
> >>>> {
> >>>> name = "T2";
> >>>> level = [ "(*,*,0)" ];
> >>>> cat_thresh = [ <=273, >273 ];
> >>>> }
> >>>> ];
> >>>> }
> >>>>
> >>>> obs = {
> >>>> message_type = [ "ADPSFC" ];
> >>>> sid_exc = [];
> >>>>
> >>>> field = [
> >>>> {
> >>>> name = "TMP";
> >>>> level = [ "Z2" ];
> >>>> cat_thresh = [ <=273, >273 ];
> >>>> }
> >>>> ];
> >>>> }
> >>>>
> >>>> Does that produce any matched pairs? I don't see the source of
the
> >>>> PREPBUFR observation data you're using, but if you're using
GDAS,
> please
> >>>> read the NOTE at the bottom of this page about the quality
marker
> that's
> >>>> assigned to surface observations:
> >>>>
http://www.dtcenter.org/met/users/downloads/observation_data.php <
> >> http://www.dtcenter.org/met/users/downloads/observation_data.php>
<
> >>>>
http://www.dtcenter.org/met/users/downloads/observation_data.php <
> >>
http://www.dtcenter.org/met/users/downloads/observation_data.php>>
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> John
> >>>>
> >>>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
> >> dawsonmattg at gmail.com> <mailto:
> >>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >> <mailto:met_help at ucar.edu>>> wrote:
> >>>>
> >>>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>>>
> >>>>> John,
> >>>>>
> >>>>> Thanks for the reply! I originally wanted to use UPP, but the
> cluster I
> >>>> ran
> >>>>> my WRF models on didn’t have much space (very fast though) so
I had
> to
> >>>>> offload all my data to another cluster my professor uses which
isn’t
> >> very
> >>>>> fast but has plenty of space. Since UPP has to have a path to
my WRF
> >>>> build
> >>>>> (excerpt below), I decided it was not feasible.
> >>>>>
> >>>>> "Overview of the scripts to run the UPP Note: It is
recommended that
> >> the
> >>>>> user refer to the run_unipost* scripts in the script/ while
reading
> >> this
> >>>>> overview.
> >>>>> 1. Set up variables:
> >>>>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
> >>>>> DOMAINPATH: directory where UPP will be run from
> >>>>> WRFPATH: path to your WRFV3 build; defaults to the environment
> variable
> >>>>> used during the installation with the configure script
> >>>>> UNI_POST_HOME: path to your UPPV2.1 build
> >>>>> POSTEXEC: path to your UPPV2.1 executables”
> >>>>>
> >>>>> As for the winds, my WRF output does supply 10 meter winds,
which I
> >> would
> >>>>> assume P_Interp would just put at the level (0,*,*), so in the
case
> >>>>> shouldn't I be able to verify winds as well?
> >>>>>
> >>>>> Anyways I tried your fix and while it does run I'm not
actually
> getting
> >>>> any
> >>>>> values. I'm fairly certain its because I specified the Level
for the
> >> obs
> >>>>> at, "P1000". I'm not sure how to specify the level as the
"surface"
> or
> >> 10
> >>>>> meters though.
> >>>>>
> >>>>> DEBUG 2:
> >>>>> ------------------------------------------------------------
> >>>>> --------------------
> >>>>> DEBUG 2:
> >>>>> DEBUG 2: Reading data for T2(0,*,*).
> >>>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0
climatology
> >> levels.
> >>>>> DEBUG 2:
> >>>>> DEBUG 2:
> >>>>> ------------------------------------------------------------
> >>>>> --------------------
> >>>>> DEBUG 2:
> >>>>> DEBUG 2: Searching 41979 observations from 6956 messages.
> >>>>> DEBUG 2:
> >>>>> DEBUG 2:
> >>>>> ------------------------------------------------------------
> >>>>> --------------------
> >>>>> DEBUG 2:
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> MSONET, over region FULL, for interpolation method NEAREST(1),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> VADWND, over region FULL, for interpolation method NEAREST(1),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
> >>>>> pairs.
> >>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using
> 0
> >>>>> pairs.
> >>>>> DEBUG 2:
> >>>>> DEBUG 2:
> >>>>> ------------------------------------------------------------
> >>>>> --------------------
> >>>>> DEBUG 2:
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> >>>>> DEBUG 1: Output file:
> >>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> >>>>> DEBUG 1: Output file:
> >>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> >>>>> DEBUG 1: Output file:
> >>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> >>>>> DEBUG 1: Output file:
> >>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> >>>>> DEBUG 1: Output file:
> >>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
> >>>>>
> >>>>>
> >>>>>
> >>>>> Matthew G. Dawson, Capt, USAF
> >>>>> AFIT Student, Civilian Institution Program
> >>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> >> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>>>
> >>>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu <mailto:met_help at ucar.edu>
> >>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
> >>>>> wrote:
> >>>>>
> >>>>> Matthew,
> >>>>>
> >>>>> I see that you have some questions about running the Point-
Stat tool.
> >>>>>
> >>>>> Regarding post-processing, I'd suggest switching from the
pinterp
> >> utility
> >>>>> to using the Unified Post-Processor (UPP). It writes output
in GRIB
> >>>> which
> >>>>> MET can easily handle. Why pinterp output could work fine for
> precip,
> >>>>> temperature, and dewpoint, MET won't be able to process the
winds
> since
> >>>>> they're defined on the staggered dimension. I realize that
running
> >> UPP,
> >>>>> yet another tool to compile and script up, can be a hassle.
But I
> >> think
> >>>>> it'll be less work in the long run.
> >>>>>
> >>>>> But as for your specific error from Point-Stat, I suspect
that'll be
> >> easy
> >>>>> to fix. In your Point-Stat config file, try using:
> >>>>> name = "T2";
> >>>>> level = [ "(0,*,*)" ];
> >>>>>
> >>>>> I often like plotting the data first:
> >>>>> met-5.2/bin/plot_data_plane \
> >>>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> >>>>> d01_2016-08-12_12:00:00_PLEV
> >>>>> \
> >>>>> T2.ps \
> >>>>> 'name="T2"; level="(0,*,*)";'
> >>>>>
> >>>>> Hopefully that'll create a PostScript plot of your data.
> >>>>>
> >>>>> Thanks,
> >>>>> John Halley Gotway
> >>>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >> <mailto:met_help at ucar.edu>>
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
> >> dawsonmattg at gmail.com> <mailto:
> >>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >>>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >> <mailto:met_help at ucar.edu>>> wrote:
> >>>>>
> >>>>>
> >>>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> >>>>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
> >> dawsonmattg at gmail.com> <mailto:
> >>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>> Queue: met_help
> >>>>> Subject: Point Stat help
> >>>>> Owner: Nobody
> >>>>> Requestors: dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com>
> >> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>> Status: new
> >>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
> <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> >> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>>>
> >>>>>
> >>>>> Hello MET help,
> >>>>>
> >>>>> I’m going to go ahead and apologize for all the
information in
> >>>>> this email, but hopefully it will help you better diagnose
what the
> >> best
> >>>>> way for me to move forward is. As part of my research I
generated 12
> >>>>> different WRF runs over the same week using the same I.C.s and
B.C.s,
> >> and
> >>>>> am currently in the process of comparing them against real
world
> >>>>> observations to see which config worked the best. I am primary
> >> concerned
> >>>>> with comparing precip, surface temp/dewpoint, and surface
winds.
> >>>>>
> >>>>> The first tool I have tried to use has been the point stat
tool.
> I
> >>>>> am using your met-5.2_bugfix package and did not find any
errors
> >>>>> while/after compiling and made sure the test files, like
> >>>>> test_point_stat.sh, all work. The data I am using is as
follows:
> >>>>>
> >>>>>
> >>>>> Instead of downloading prepbufer files and
converting
> them
> >>>>> with the PB2NC tool, I just used the UCAR site to do it for me
(
> >>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su <
> >> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
> >>>> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
> >> http://rda.ucar.edu/datasets/>
> >>>> ds337.0/index.html#forms/337_subset.php?_da=y>
> >>>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> >> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
> >>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> >> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
> >>>>> subset.php?_da=y>)
> >>>>> Request Detail:
> >>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>>>> NCEP Verification Regions : SEC
> >>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> >> PRMSL
> >>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> >>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>>>> Quality Mark Threshold : 9
> >>>>> File Compression : gz
> >>>>> Data Output Format : NETCDF
> >>>>>
> >>>>>
> >>>>>
> >>>>> To convert my WRF data into a readable format I used
P_Interp. I
> >>>>> am now realizing this might not be the best way forward, but
seemed
> the
> >>>>> easiest to set up as I had to offload all my model output to a
> >> different
> >>>>> cluster that I did not configure WRF on. I have been a bit
confused
> as
> >>>>> P_Interp says it can unstager data to pressure levels, but on
your
> >>>> website
> >>>>> it says that P_Interp cannot onstager data (at least for use
with
> MODE
> >>>> and
> >>>>> other tools). Either way do you think I should try use a
different
> >>>>> pre-processing software to unpack my WRF data or will P_Interp
be
> >>>>> sufficient to compare precip, surface temp/dewpoint and winds?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> When I run my file PointStat.sh using the attached
> >>>>> PointStatConfig1 file, I get the following data error message:
> >>>>>
> >>>>> *** Running Point-Stat on prepbuffer files ***
> >>>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> >>>>> bugfix/share/met/config/PointStatConfig_default
> >>>>> DEBUG 1: User Config File: config/PointStatConfig
> >>>>> GSL_RNG_TYPE=mt19937
> >>>>> GSL_RNG_SEED=1
> >>>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> >>>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> >>>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> >>>>> .gdas.225564.2016081200.nc
> >>>>> DEBUG 2:
> >>>>> DEBUG 2: ------------------------------
> ------------------------------
> >>>>> --------------------
> >>>>> DEBUG 2:
> >>>>> DEBUG 2: Reading data for T2(*,*,0).
> >>>>> WARNING:
> >>>>> WARNING: PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
> >>>> double
> >>>>> &) const -> star found in bad slot
> >>>>> WARNING:
> >>>>> ERROR :
> >>>>> ERROR : PinterpFile::valid_time(int) const -> range check
error
> >>>>> ERROR :
> >>>>>
> >>>>>
> >>>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
> >>>>> float T2(Time, south_north, west_east) ;
> >>>>> T2:FieldType = 104 ;
> >>>>> T2:MemoryOrder = "XY " ;
> >>>>> T2:description = "TEMP at 2 M" ;
> >>>>> T2:units = "K" ;
> >>>>> T2:stagger = "" ;
> >>>>> T2:coordinates = "XLONG XLAT XTIME" ;
> >>>>> T2:missing_value = 1.e+36f ;
> >>>>>
> >>>>> I am not sure if the issue is that P_Interp is not properly
> extracting
> >>>>> this information, or If I just need to change my
PointStatConfig1
> file.
> >>>>>
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>>
> >>>>> Matthew G. Dawson, Capt, USAF
> >>>>> AFIT Student, Civilian Institution Program
> >>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> >> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
> >>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
> >> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
> >> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
> >>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>>>
> >>>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
> >> tcram at ucar.edu> <mailto:
> >>>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
> >>>>>
> >>>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
> <mailto:
> >> tcram at ucar.edu>>>> wrote:
> >>>>>
> >>>>>
> >>>>> Hi Matthew,
> >>>>>
> >>>>> I recommend contacting MET support (cc'd here). It's possible
you
> >>>>>
> >>>>> should be using the PrepBUFR data instead of the NetCDF data
in MET,
> >> but
> >>>>> having no experience using MET, I am merely speculating on
this. MET
> >>>>> support should be able to help you out.
> >>>>>
> >>>>>
> >>>>> Good luck,
> >>>>> - Tom
> >>>>>
> >>>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew <
> dawsonmattg at gmail.com
> >> <mailto:dawsonmattg at gmail.com>
> >>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>>
> >>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
> <mailto:
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
> >>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
> >> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
> >>>>>
> >>>>> Hey Thomas
> >>>>>
> >>>>> I was able to get the data download with no issues, however I
have
> been
> >>>>>
> >>>>> having issues with actually using that data in MET. I am
trying to
> >>>> compare
> >>>>> it to some WRF output (used P-Interp to convert into a MET
readable
> >>>>> format), but the PointStatConfig file keeps having issues (I’m
not
> >> sure I
> >>>>> filled it out correctly). Anyways I was wondering if you, or
anyone
> >>>>> happened to know of an online resource, or even someone who
had a
> >>>>> configuration set up for comparing data against WRF data so I
can
> >> compare
> >>>>> what I have against there config files and hopefully figure
out
> where I
> >>>> am
> >>>>> going wrong. I’ve been looking through the MET user guide but
haven’t
> >>>> found
> >>>>> a solution yet. Thanks!
> >>>>>
> >>>>>
> >>>>> Matthew G. Dawson, Capt, USAF
> >>>>> AFIT Student, Civilian Institution Program
> >>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> >> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
> >>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
> >> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
> >> <mailto:
> >>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
> >>>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-
5427
> >> <tel:%28904%29-333-5427>
> >>>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
> >>>>> <%28904%29-333-5427>>
> >>>>>
> >>>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
> >>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> >> <mailto:tcram at ucar.edu>>
> >>>>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
> >> <mailto:tcram at ucar.edu>>>>
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
> >>>>>
> >>>>> Observations has completed.
> >>>>>
> >>>>> Please login to the NCAR RDA server at http://rda.ucar.edu <
> >> http://rda.ucar.edu/> <
> >>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
> >>>>>
> >>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
> >> http://rda.ucar.edu/>>>, then download your files
> >>>> from the
> >>>>>
> >>>>> following URL:
> >>>>>
> >>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> >> http://rda.ucar.edu/#dsrqst/DAWSON225564/> <
> http://rda.ucar.edu/#dsrqst/D
> >> <http://rda.ucar.edu/#dsrqst/D>
> >>>> AWSON225564/> <
> >>>>>
> >>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> >> http://rda.ucar.edu/#dsrqst/DAWSON225564/> <
> http://rda.ucar.edu/#dsrqst/D
> >> <http://rda.ucar.edu/#dsrqst/D>
> >>>> AWSON225564/>>
> >>>>>
> >>>>>
> >>>>> Request ID: DAWSON225564
> >>>>>
> >>>>> Request Detail:
> >>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>>>> NCEP Verification Regions : SEC
> >>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
> >>>>>
> >>>>> PRMSL
> >>>>>
> >>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
> >>>>>
> >>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>>>>
> >>>>> Quality Mark Threshold : 9
> >>>>> File Compression : gz
> >>>>> Data Output Format : NETCDF
> >>>>>
> >>>>>
> >>>>> The "rda-request-manager" command line tool provides an
additional
> >>>>>
> >>>>> option for users to download
> >>>>>
> >>>>> request output files on unix based systems. The
> "rda-request-manager"
> >>>>>
> >>>>> tool can be accessed at:
> >>>>>
> >>>>>
> >>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> >> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
> >>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> >> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
> >>>>>
> >>>>> The data provided in your data request are a subset of the
NCAR RDA
> >>>>>
> >>>>> dataset ds337.0 --
> >>>>>
> >>>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
> >>>>>
> >>>>> format), May 1997 - Continuing'. Please see
> >>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/> <
> >> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
> >>>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
> >> http://rda.ucar.edu/datasets/ds337.0/> <
> >>>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
> >> ds337.0/>>> for more information.
> >>>>>
> >>>>>
> >>>>> Your data will remain on our system for 5 days. If this is
not
> >>>>>
> >>>>> sufficient time for you to retrieve
> >>>>>
> >>>>> your data, please let me know as soon as possible, so that I
can
> >>>>>
> >>>>> prevent the data files from being
> >>>>>
> >>>>> purged too soon.
> >>>>>
> >>>>> If you have any questions related to this data request, please
let me
> >>>>>
> >>>>> know by replying to this
> >>>>>
> >>>>> email.
> >>>>>
> >>>>> Sincerely,
> >>>>>
> >>>>> Thomas Cram
> >>>>> NCAR/CISL/Data Support Section
> >>>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-
1217
> >> <tel:%28303%29-497-1217>
> >>>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
> >>>>> <%28303%29-497-1217>>
> >>>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> >> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
> >> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >>>>
> >>>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/> <
> http://rda.ucar.edu/
> >> <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
> >>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Thomas Cram
> >>>>> NCAR / CISL / DSS
> >>>>> tel: +1-303-497-1217 <(303)%20497-1217>
> >>>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:
> tcram at ucar.edu
> >> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
> >> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >>>>
> >>>>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/
<
> >> http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
> >>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>>>
> >>>>>
> >>>>> Matthew G. Dawson, Capt, USAF
> >>>>> AFIT Student, Civilian Institution Program
> >>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> >> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
> >>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>
> >>
> >>
> >
>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Mon Feb 27 19:41:01 2017
John,
So I have been working on trying to get everything up and running but
I’m still having some issues.
I use madis2nc to convert my files into the appropriate format. From
that I use the point_stat to evaluate the results producing the
applicable format (CNT, sl1l2, and vl1l2). When I look at the result
.stat file (attached) I am assuming it is saying there are only three
stations that it is getting obs from? If thats the case then I’m not
sure the evaluation is worth the additional effort but I am confused
as there should be many more station as it is maids mesonet data. I
attached a log of my point stat and maids conversion if that helps.
Also I was curious if you had a possible fix to get RH to work when I
am using point stat ( its in the RH error log). I could be wrong but I
am fairly certain the P_interp properly pulled the field out I just
don’t know what the fourth argument is supposed to be. Also if it
helps I can shoot you my config scripts for each one, Thanks!
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Mon Feb 27 19:41:01 2017
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Mon Feb 27 19:41:01 2017
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 22, 2017, at 11:32 AM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>
> Matthew,
>
> Sounds like an interesting project. Yes, the MET tools can be used
to
> perform the individual comparisons, but there remains a lot of work
to be
> done to script up the calls to them in the right order to accomplish
your
> task.
>
> I've done a lot of that type of work using PERL and shell scripts
(mostly
> ksh). I think we've gotten to the point in the development of the
MET
> software, that setting up the controlling scripts is the biggest
hurdle to
> using the software. In the last few months we've begun work on a
system
> we're calling MET+ which is a set of python wrapper scripts for the
MET
> tools to "automate" this scripting as much as possible. This work
is
> driven mainly by the needs of the operational modelling community.
But
> hopefully, a user, like yourself, would be able to set up a
configuration
> script which the python wrapper scripts use to call the MET tools in
the
> right order. But that's down the road. For now, you're stuck doing
it
> yourself using whatever scripting language you prefer.
>
> It sounds like you're interested in continuous statistics (ME, RMSE)
for
> surface variables and categorical stats (MODE objects and maybe ETS)
for
> precip. You'd ultimately use Point-Stat for surface point-based
> verification, Grid-Stat for categorical verification of precip, and
MODE
> for an object-based evaluation of precip. While you could run
Point-Stat
> for every 15 minute output, that may be overkill. I'd suggest doing
it
> hourly, unless there's a good reason to do it more often.
>
> You run Point-Stat, Grid-Stat, and MODE once for each combination of
model
> and output time. So you'll do many runs of those tools. From
Point-Stat,
> you want the CNT line type (continuous stats) as well as the SL1L2
and
> VL1L2 line types (scalar and vector parial sums) which can be
aggregated
> later. You could consider dumping the individual matched pair
values (MPR
> line type) but that can get to be a lot of data very quickly. From
> Grid-Stat, you want the CTC and CTS line type (contingency table
counts and
> statistics). Prior to running Point-Stat, you'd run PB2NC to pre-
process
> PREPBUFR point observations. And prior to running Grid-Stat or
MODE you
> may need to run pcp_combine if you need to change the accumulation
> intervals of your precip data. Lastly, the STAT-Analysis tool is
used to
> read the output of Point-Stat and Grid-Stat and accumulate
statistics over
> the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
> lines from each run and derive aggregated statistics. Similarly, it
can be
> used to aggregate CTC lines from each run and derive aggregated
categorical
> statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
(FBIAS).
>
> So lots of little steps to accomplish, but once you get the calls
scripted
> up, hopefully it'll go smoothly for you.
>
> Hope that helps.
>
> Thanks,
> John
>
> On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>>
>> John,
>>
>> Thanks for all the good info! Heres a little scoop on what I am
trying to
>> accomplish if your interested, if not I have answers to your
questions
>> starting at **********
>>
>> You might be familiar with the AMU (Applied Meteorology Unit
>> https://science.ksc.nasa.gov/amu/history.html <
>> https://science.ksc.nasa.gov/amu/history.html>) that is down in
cape
>> canaveral. They were tasked with setting up a mesoscale model to
improve
>> operational forecast, and ran a few different verification
statistics (ME,
>> RMSE, MODE) on a number of different configurations your interested
here a
>> link to their first Technical Report (Watson_2013-https://ntrs.
>> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
>> jsp?R=20150000384> ). Several changes have occurred over the past
few
>> years included triple nested model as opposed to double nested,
smaller
>> grid space, and a myriad of additional observations/assimilated
data sets
>> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
>> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
>> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
>> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
>>
>> Talking with the head civilian down their, lightning delays are
their
>> primary problem, as well as forecasting convection in SE flow. So
after
>> reading up on their configuration it seemed like using a more up to
date
>> Microphysical model would produce better precipitation statistics
and a
>> better overall approximation of developing convection. So I used 3
>> different microphysics schemes to create 12 different model runs,
which
>> show some reasonable difference when plotting rain totals ect.
>>
>> ************
>> So with the 12 different models I am trying to create a “scorecard”
to
>> show which ones more accurately predicted the surface
precipitation, wind
>> speed, direction, T, Td.
>>
>> The week of model runs were purposely selected over a period
predominantly
>> SE flow (august) which they have trouble forecasting for. This is
somewhat
>> of a sub-regime in their overall summertime regime, but since most
>> convection is characterized by mesoscale process (sea-breeze,
river-breeze)
>> it could be extended for the entire summer months. The model was
PRIMARY
>> developed to help summertime forecast as lightning delays cost them
lots of
>> $$$, so I’m not even sure if they rely on this model, as opposed to
some of
>> the national centers, during other seasons.
>>
>> Since the prior work from the above papers used ME, RMSE in the
point stat
>> tool and MODE for precip I want to try use the same techniques.
>>
>> I guess my real question would be how I should go about setting
everything
>> up, coding.
>>
>> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
>> (precip) values for each day and for the total week. Since my wrf
outfiles
>> are in 15 min intervals, over 24 hours I’m not sure how to specify
in point
>> stat how to read in all these files and produce one RMSE and ME
value for
>> the day, or produce them for each time and them calculate the total
for the
>> day. I’m not sure if I need to somehow mesh all my wrfout files
into one
>> file and then have point stat use that or if there is a simpler
way.
>>
>>
>> Matthew G. Dawson, Capt, USAF
>> AFIT Student, Civilian Institution Program
>> Email: Dawsonmattg at gmail.com
>> Cell: (904)-333-5427
>>
>>> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>>
>>> Matthew,
>>>
>>> Great, I'm glad you were able to get it up and running!
>>>
>>> There's no need to acknowledge me directly, but I'd appreciate you
>>> acknowledging the MET software package. The more advertising we
can get
>>> for future funding, the better!
>>>
>>> As for your choice of verification datasets, that's usually
limited by
>> your
>>> domain, the timing of your model output, and the actual
verification
>>> questions you're trying to answer. With output from 12 different
models,
>>> what are you actually trying to assess? Is it just a scorecard to
see
>>> which model verifies better overall? Or do you have more specific
>>> questions? With only one week of data to compare, you can do an
>> objective
>>> comparison... but will your results hold up during the other 3
seasons?
>> Or
>>> during other weather regimes? So I'd be hesitant in using only
one week
>> of
>>> data to make strong claims about overall performance.
>>>
>>> With data every 15 minutes, I believe that the surface data shows
up
>> pretty
>>> in PREPBUFR pretty regularly. So you could do surface
verification up to
>>> every 15 minutes if you'd like. While there are a very small
number of
>>> soundings in PREPBUFR files at off-hours, we generally only verify
>>> upper-air at 00Z and 12Z.
>>>
>>> For choice of precipitation analysis... I'd suggest reading about
>> StageII,
>>> StageIV, CCPA, and MRMS. We've used all of them on different
projects
>>> within the DTC. MRMS is probably the one being most actively
worked on
>>> right now. Depending on what questions you're asking, you could
also
>>> compare against URMA which is a gridded CONUS analysis product.
>>>
>>> Let me warn you that I'm a software engineer, not a statistician
or
>>> atmospheric scientist. But we do have both of them on the MET
team. So
>> if
>>> you have specific questions in those areas, I could route them to
the
>> right
>>> person.
>>>
>>> Hope that helps.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> via RT <
>>> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>>>
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>>>>
>>>> Hey John,
>>>>
>>>> Sorry for the late reply, but your suggestion worked! I
also
>>>> figured out I was referencing the wrong file time which of course
would
>>>> come back with no results.
>>>>
>>>> I was curious though how you would suggest tackling my
“project".
>>>> I have 12 different model outputs (the same domain) over the same
week
>> that
>>>> I want to try verify. The model output occurs at 15 min
intervals, and
>> I am
>>>> primary interested in precipitation skill scores (would like to
use the
>>>> MODE tool), but the temperature, Td, wind speed and direction
will also
>> be
>>>> useful. I was planing on using the MODE tool to evaluate the SFC
precip
>> to
>>>> stage II radar data unless you would recommend another way. Also
please
>> let
>>>> me know if you would like me to add you in my acknowledgement
section
>> for
>>>> help with this tool kit, thanks!
>>>>
>>>> Matthew G. Dawson, Capt, USAF
>>>> AFIT Student, Civilian Institution Program
>>>> Email: Dawsonmattg at gmail.com
>>>> Cell: (904)-333-5427
>>>>
>>>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
>>>> met_help at ucar.edu> wrote:
>>>>>
>>>>> According to our records, your request has been resolved. If you
have
>> any
>>>>> further questions or concerns, please respond to this message.
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
>> met_help at ucar.edu
>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>>>
>>>> Matthew,
>>>>
>>>> The verification of surface variables is done in a pretty
simplistic
>> way by
>>>> specifying the message type.
>>>>
>>>> The ADPSFC and SFCSHP message types are assumed to exist at the
surface
>> and
>>>> are used to verifying "surface" variables such as 2m temperature
and
>> 10-m
>>>> winds. And ONLYSF is a short-cut for combining land-based ADPSFC
and
>>>> water-based SFCSHP observations together. Your Point-Stat config
file
>>>> should look something like this:
>>>>
>>>> fcst = {
>>>> field = [
>>>> {
>>>> name = "T2";
>>>> level = [ "(*,*,0)" ];
>>>> cat_thresh = [ <=273, >273 ];
>>>> }
>>>> ];
>>>> }
>>>>
>>>> obs = {
>>>> message_type = [ "ADPSFC" ];
>>>> sid_exc = [];
>>>>
>>>> field = [
>>>> {
>>>> name = "TMP";
>>>> level = [ "Z2" ];
>>>> cat_thresh = [ <=273, >273 ];
>>>> }
>>>> ];
>>>> }
>>>>
>>>> Does that produce any matched pairs? I don't see the source of
the
>>>> PREPBUFR observation data you're using, but if you're using GDAS,
please
>>>> read the NOTE at the bottom of this page about the quality marker
that's
>>>> assigned to surface observations:
>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>> http://www.dtcenter.org/met/users/downloads/observation_data.php> <
>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>> http://www.dtcenter.org/met/users/downloads/observation_data.php>>
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> John
>>>>
>>>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>> wrote:
>>>>
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>
>>>>> John,
>>>>>
>>>>> Thanks for the reply! I originally wanted to use UPP, but the
cluster I
>>>> ran
>>>>> my WRF models on didn’t have much space (very fast though) so I
had to
>>>>> offload all my data to another cluster my professor uses which
isn’t
>> very
>>>>> fast but has plenty of space. Since UPP has to have a path to my
WRF
>>>> build
>>>>> (excerpt below), I decided it was not feasible.
>>>>>
>>>>> "Overview of the scripts to run the UPP Note: It is recommended
that
>> the
>>>>> user refer to the run_unipost* scripts in the script/ while
reading
>> this
>>>>> overview.
>>>>> 1. Set up variables:
>>>>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
>>>>> DOMAINPATH: directory where UPP will be run from
>>>>> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
>>>>> used during the installation with the configure script
>>>>> UNI_POST_HOME: path to your UPPV2.1 build
>>>>> POSTEXEC: path to your UPPV2.1 executables”
>>>>>
>>>>> As for the winds, my WRF output does supply 10 meter winds,
which I
>> would
>>>>> assume P_Interp would just put at the level (0,*,*), so in the
case
>>>>> shouldn't I be able to verify winds as well?
>>>>>
>>>>> Anyways I tried your fix and while it does run I'm not actually
getting
>>>> any
>>>>> values. I'm fairly certain its because I specified the Level for
the
>> obs
>>>>> at, "P1000". I'm not sure how to specify the level as the
"surface" or
>> 10
>>>>> meters though.
>>>>>
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Reading data for T2(0,*,*).
>>>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0 climatology
>> levels.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Searching 41979 observations from 6956 messages.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>> pairs.
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>> ------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
>>>>> DEBUG 1: Output file:
>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
>>>>> DEBUG 1: Output file:
>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
>>>>> DEBUG 1: Output file:
>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>>>>>
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>
>>>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
>> met_help at ucar.edu <mailto:met_help at ucar.edu>
>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
>>>>> wrote:
>>>>>
>>>>> Matthew,
>>>>>
>>>>> I see that you have some questions about running the Point-Stat
tool.
>>>>>
>>>>> Regarding post-processing, I'd suggest switching from the
pinterp
>> utility
>>>>> to using the Unified Post-Processor (UPP). It writes output in
GRIB
>>>> which
>>>>> MET can easily handle. Why pinterp output could work fine for
precip,
>>>>> temperature, and dewpoint, MET won't be able to process the
winds since
>>>>> they're defined on the staggered dimension. I realize that
running
>> UPP,
>>>>> yet another tool to compile and script up, can be a hassle. But
I
>> think
>>>>> it'll be less work in the long run.
>>>>>
>>>>> But as for your specific error from Point-Stat, I suspect
that'll be
>> easy
>>>>> to fix. In your Point-Stat config file, try using:
>>>>> name = "T2";
>>>>> level = [ "(0,*,*)" ];
>>>>>
>>>>> I often like plotting the data first:
>>>>> met-5.2/bin/plot_data_plane \
>>>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
>>>>> d01_2016-08-12_12:00:00_PLEV
>>>>> \
>>>>> T2.ps \
>>>>> 'name="T2"; level="(0,*,*)";'
>>>>>
>>>>> Hopefully that'll create a PostScript plot of your data.
>>>>>
>>>>> Thanks,
>>>>> John Halley Gotway
>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>
>>>>>
>>>>>
>>>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>> <mailto:met_help at ucar.edu>>> wrote:
>>>>>
>>>>>
>>>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
>>>>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
>> dawsonmattg at gmail.com> <mailto:
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>> Queue: met_help
>>>>> Subject: Point Stat help
>>>>> Owner: Nobody
>>>>> Requestors: dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>
>>>>>
>>>>> Hello MET help,
>>>>>
>>>>> I’m going to go ahead and apologize for all the information
in
>>>>> this email, but hopefully it will help you better diagnose what
the
>> best
>>>>> way for me to move forward is. As part of my research I
generated 12
>>>>> different WRF runs over the same week using the same I.C.s and
B.C.s,
>> and
>>>>> am currently in the process of comparing them against real world
>>>>> observations to see which config worked the best. I am primary
>> concerned
>>>>> with comparing precip, surface temp/dewpoint, and surface winds.
>>>>>
>>>>> The first tool I have tried to use has been the point stat
tool. I
>>>>> am using your met-5.2_bugfix package and did not find any errors
>>>>> while/after compiling and made sure the test files, like
>>>>> test_point_stat.sh, all work. The data I am using is as follows:
>>>>>
>>>>>
>>>>> Instead of downloading prepbufer files and
converting them
>>>>> with the PB2NC tool, I just used the UCAR site to do it for me
(
>>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
>>>> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
>> http://rda.ucar.edu/datasets/>
>>>> ds337.0/index.html#forms/337_subset.php?_da=y>
>>>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
>>>>> subset.php?_da=y>)
>>>>> Request Detail:
>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>> NCEP Verification Regions : SEC
>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>> PRMSL
>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>> Quality Mark Threshold : 9
>>>>> File Compression : gz
>>>>> Data Output Format : NETCDF
>>>>>
>>>>>
>>>>>
>>>>> To convert my WRF data into a readable format I used
P_Interp. I
>>>>> am now realizing this might not be the best way forward, but
seemed the
>>>>> easiest to set up as I had to offload all my model output to a
>> different
>>>>> cluster that I did not configure WRF on. I have been a bit
confused as
>>>>> P_Interp says it can unstager data to pressure levels, but on
your
>>>> website
>>>>> it says that P_Interp cannot onstager data (at least for use
with MODE
>>>> and
>>>>> other tools). Either way do you think I should try use a
different
>>>>> pre-processing software to unpack my WRF data or will P_Interp
be
>>>>> sufficient to compare precip, surface temp/dewpoint and winds?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> When I run my file PointStat.sh using the attached
>>>>> PointStatConfig1 file, I get the following data error message:
>>>>>
>>>>> *** Running Point-Stat on prepbuffer files ***
>>>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
>>>>> bugfix/share/met/config/PointStatConfig_default
>>>>> DEBUG 1: User Config File: config/PointStatConfig
>>>>> GSL_RNG_TYPE=mt19937
>>>>> GSL_RNG_SEED=1
>>>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
>>>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
>>>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
>>>>> .gdas.225564.2016081200.nc
>>>>> DEBUG 2:
>>>>> DEBUG 2:
------------------------------------------------------------
>>>>> --------------------
>>>>> DEBUG 2:
>>>>> DEBUG 2: Reading data for T2(*,*,0).
>>>>> WARNING:
>>>>> WARNING: PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
>>>> double
>>>>> &) const -> star found in bad slot
>>>>> WARNING:
>>>>> ERROR :
>>>>> ERROR : PinterpFile::valid_time(int) const -> range check error
>>>>> ERROR :
>>>>>
>>>>>
>>>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
>>>>> float T2(Time, south_north, west_east) ;
>>>>> T2:FieldType = 104 ;
>>>>> T2:MemoryOrder = "XY " ;
>>>>> T2:description = "TEMP at 2 M" ;
>>>>> T2:units = "K" ;
>>>>> T2:stagger = "" ;
>>>>> T2:coordinates = "XLONG XLAT XTIME" ;
>>>>> T2:missing_value = 1.e+36f ;
>>>>>
>>>>> I am not sure if the issue is that P_Interp is not properly
extracting
>>>>> this information, or If I just need to change my
PointStatConfig1 file.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
>>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>
>>>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
>> tcram at ucar.edu> <mailto:
>>>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
>>>>>
>>>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:
>> tcram at ucar.edu>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Matthew,
>>>>>
>>>>> I recommend contacting MET support (cc'd here). It's possible
you
>>>>>
>>>>> should be using the PrepBUFR data instead of the NetCDF data in
MET,
>> but
>>>>> having no experience using MET, I am merely speculating on this.
MET
>>>>> support should be able to help you out.
>>>>>
>>>>>
>>>>> Good luck,
>>>>> - Tom
>>>>>
>>>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
>> <mailto:dawsonmattg at gmail.com>
>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>>
>>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
>>>>>
>>>>> Hey Thomas
>>>>>
>>>>> I was able to get the data download with no issues, however I
have been
>>>>>
>>>>> having issues with actually using that data in MET. I am trying
to
>>>> compare
>>>>> it to some WRF output (used P-Interp to convert into a MET
readable
>>>>> format), but the PointStatConfig file keeps having issues (I’m
not
>> sure I
>>>>> filled it out correctly). Anyways I was wondering if you, or
anyone
>>>>> happened to know of an online resource, or even someone who had
a
>>>>> configuration set up for comparing data against WRF data so I
can
>> compare
>>>>> what I have against there config files and hopefully figure out
where I
>>>> am
>>>>> going wrong. I’ve been looking through the MET user guide but
haven’t
>>>> found
>>>>> a solution yet. Thanks!
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
>> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
>> <mailto:
>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
>> <tel:%28904%29-333-5427>
>>>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
>>>>> <%28904%29-333-5427>>
>>>>>
>>>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>>
>>>>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>>>>>
>>>>> Observations has completed.
>>>>>
>>>>> Please login to the NCAR RDA server at http://rda.ucar.edu <
>> http://rda.ucar.edu/> <
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
>>>>>
>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
>> http://rda.ucar.edu/>>>, then download your files
>>>> from the
>>>>>
>>>>> following URL:
>>>>>
>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>> <http://rda.ucar.edu/#dsrqst/D>
>>>> AWSON225564/> <
>>>>>
>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>> <http://rda.ucar.edu/#dsrqst/D>
>>>> AWSON225564/>>
>>>>>
>>>>>
>>>>> Request ID: DAWSON225564
>>>>>
>>>>> Request Detail:
>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>> NCEP Verification Regions : SEC
>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>>>>>
>>>>> PRMSL
>>>>>
>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>>
>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>>
>>>>> Quality Mark Threshold : 9
>>>>> File Compression : gz
>>>>> Data Output Format : NETCDF
>>>>>
>>>>>
>>>>> The "rda-request-manager" command line tool provides an
additional
>>>>>
>>>>> option for users to download
>>>>>
>>>>> request output files on unix based systems. The "rda-request-
manager"
>>>>>
>>>>> tool can be accessed at:
>>>>>
>>>>>
>>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
>>>>>
>>>>> The data provided in your data request are a subset of the NCAR
RDA
>>>>>
>>>>> dataset ds337.0 --
>>>>>
>>>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>>>>>
>>>>> format), May 1997 - Continuing'. Please see
>>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/> <
>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
>>>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
>> http://rda.ucar.edu/datasets/ds337.0/> <
>>>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
>> ds337.0/>>> for more information.
>>>>>
>>>>>
>>>>> Your data will remain on our system for 5 days. If this is not
>>>>>
>>>>> sufficient time for you to retrieve
>>>>>
>>>>> your data, please let me know as soon as possible, so that I can
>>>>>
>>>>> prevent the data files from being
>>>>>
>>>>> purged too soon.
>>>>>
>>>>> If you have any questions related to this data request, please
let me
>>>>>
>>>>> know by replying to this
>>>>>
>>>>> email.
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Thomas Cram
>>>>> NCAR/CISL/Data Support Section
>>>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-1217
>> <tel:%28303%29-497-1217>
>>>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
>>>>> <%28303%29-497-1217>>
>>>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/
>> <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thomas Cram
>>>>> NCAR / CISL / DSS
>>>>> tel: +1-303-497-1217 <(303)%20497-1217>
>>>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/ <
>> http://rda.ucar.edu/>> <http://rda.ucar.edu/ <http://rda.ucar.edu/>
<
>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>
>>
>>
>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Tue Feb 28 16:20:21 2017
Matt,
I see you have some questions about the output of Point-Stat. Thanks
for
sending some data for me to look at.
First, here's line number 32 of the "pointlog" that you sent to me:
DEBUG 2: Processing T2(0,*,*) versus TMP/Z2, for observation type
ADPSFC, over region FULL, for interpolation method NEAREST(1), using
126
pairs.
This is telling you that the statistics for 2-m temperature were
computed
using 126 matched pairs. Further down, the log file tells you that it
used
128 pairs for the U and V components of wind. These numbers also show
up
in the TOTAL column of the ".stat" file you sent to me. Look at the
column
right after the "LINE_TYPE" column.
I have no idea why you're assuming it's only getting observations from
3
locations.
If you want to see that individual matched pair values, including the
station location and times, just turn on the MPR output line type in
the
Point-Stat output_flag configuration file option. And try setting it
to
"BOTH" so that it creates an output file named "point_stat*_mpr.txt".
That'll include a nice header row to make the data easier to read.
Next, please try running Point-Stat at verbosity level 3 (i.e. -v 3).
That'll dump out the following type of log messages for each
verification
task:
DEBUG 3: Number of matched pairs = 155
DEBUG 3: Observations processed = 89893
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: GRIB code = 79360
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 5
DEBUG 3: Rejected: level mismatch = 9607
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 344
DEBUG 3: Rejected: masking region = 422
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
This tells you the number of matched pairs found for that task and
also
lists counts of reasons *why* the other observations were not used for
this
task. I find this info very helpful.
As for the RH error, the pinterp output likely contains RH for every
model
level. That's what the 4th dimension is for. Use 'ncdump -h' to look
at
the pinterp variable:
float RH(Time, num_metgrid_levels, south_north, west_east) ;
I assume you want to evaluate RH at the surface. Looks like that
isn't
included directly in the WRF (and thus pinterp) output. You have two
choices.
- You could just compare the first model level to surface observations
using:
name = "RH"; level = "(0,0,*,*)";
- Since WRF is "terrain-following" perhaps that's close enough. If
not,
you could post-process your WRF output using UPP instead of pinterp.
I'm
guessing UPP can be configurable to write out RH at the surface.
Hope that helps clarify.
Thanks,
John
On Mon, Feb 27, 2017 at 7:41 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> John,
>
> So I have been working on trying to get everything up and running
but I’m
> still having some issues.
>
> I use madis2nc to convert my files into the appropriate format. From
that
> I use the point_stat to evaluate the results producing the
applicable
> format (CNT, sl1l2, and vl1l2). When I look at the result .stat file
> (attached) I am assuming it is saying there are only three stations
that it
> is getting obs from? If thats the case then I’m not sure the
evaluation is
> worth the additional effort but I am confused as there should be
many more
> station as it is maids mesonet data. I attached a log of my point
stat and
> maids conversion if that helps.
>
> Also I was curious if you had a possible fix to get RH to work when
I am
> using point stat ( its in the RH error log). I could be wrong but I
am
> fairly certain the P_interp properly pulled the field out I just
don’t know
> what the fourth argument is supposed to be. Also if it helps I can
shoot
> you my config scripts for each one, Thanks!
>
>
>
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Tue Feb 28 17:45:22 2017
John,
Phew! I was getting the 3 locations for looking at the .stat file
since for there were only 3 lines for tmp, 3 lines for u, and 3 lines
for v. I wasn’t sure if the matched pairs were the obs locations or if
looking at the .stat number of lines for each variable indicated the
observations.
I’ll give the the RH value a shot, but was also curious if I need to
be doing anything special other than comparing u and v fields to get
wind direction. When looking through the MET manual it seems like to
get wind direction stats you just use a variant of grid stat at the
end (a.k.a. not something I need to define in point stat).
Lastly I’m hoping you maybe have a solution to the issue I am running
into when using pcp_combine for precip accumulation on stage IV data.
My issue is that I want to add up all the 1hr accumulations over a
time span of 23 hours which spans over 2 days (DD_HH) 12_06Z-13_05Z.
So while I am asking for a 23 hour accumulation, I can’t figure out a
way to change the day once it reaches the 23rd hour so that it looks
at the next days 00Z (see pcp_combine, and acclog files). I saw the
add/subtract ability in pcp_combine, which for the observation side
wouldn’t be too bad, but to try do this for 12 model runs with the
added issue of changing the initialization times would be a bit too
time consuming.
I would think there could be a work around maybe by putting an if
statement in a loop somehow?
------------------------------------------------
Subject: Point Stat help
From: dawsonmattg at gmail.com
Time: Tue Feb 28 17:45:22 2017
Anyways sorry for the constant pestering, but I at least I have loops
now to run through the point stat process for all my data so getting
closer to getting results so thanks again!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 28, 2017, at 6:20 PM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>
> Matt,
>
> I see you have some questions about the output of Point-Stat.
Thanks for
> sending some data for me to look at.
>
> First, here's line number 32 of the "pointlog" that you sent to me:
> DEBUG 2: Processing T2(0,*,*) versus TMP/Z2, for observation type
> ADPSFC, over region FULL, for interpolation method NEAREST(1), using
126
> pairs.
>
> This is telling you that the statistics for 2-m temperature were
computed
> using 126 matched pairs. Further down, the log file tells you that
it used
> 128 pairs for the U and V components of wind. These numbers also
show up
> in the TOTAL column of the ".stat" file you sent to me. Look at the
column
> right after the "LINE_TYPE" column.
>
> I have no idea why you're assuming it's only getting observations
from 3
> locations.
>
> If you want to see that individual matched pair values, including
the
> station location and times, just turn on the MPR output line type in
the
> Point-Stat output_flag configuration file option. And try setting
it to
> "BOTH" so that it creates an output file named
"point_stat*_mpr.txt".
> That'll include a nice header row to make the data easier to read.
>
> Next, please try running Point-Stat at verbosity level 3 (i.e. -v
3).
> That'll dump out the following type of log messages for each
verification
> task:
> DEBUG 3: Number of matched pairs = 155
> DEBUG 3: Observations processed = 89893
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: GRIB code = 79360
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 5
> DEBUG 3: Rejected: level mismatch = 9607
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 344
> DEBUG 3: Rejected: masking region = 422
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
>
> This tells you the number of matched pairs found for that task and
also
> lists counts of reasons *why* the other observations were not used
for this
> task. I find this info very helpful.
>
> As for the RH error, the pinterp output likely contains RH for every
model
> level. That's what the 4th dimension is for. Use 'ncdump -h' to
look at
> the pinterp variable:
> float RH(Time, num_metgrid_levels, south_north, west_east) ;
>
> I assume you want to evaluate RH at the surface. Looks like that
isn't
> included directly in the WRF (and thus pinterp) output. You have
two
> choices.
> - You could just compare the first model level to surface
observations
> using:
> name = "RH"; level = "(0,0,*,*)";
> - Since WRF is "terrain-following" perhaps that's close enough. If
not,
> you could post-process your WRF output using UPP instead of pinterp.
I'm
> guessing UPP can be configurable to write out RH at the surface.
>
> Hope that helps clarify.
>
> Thanks,
> John
>
>
>
> On Mon, Feb 27, 2017 at 7:41 PM, dawsonmattg at gmail.com via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>>
>> John,
>>
>> So I have been working on trying to get everything up and running
but I’m
>> still having some issues.
>>
>> I use madis2nc to convert my files into the appropriate format.
>From that
>> I use the point_stat to evaluate the results producing the
applicable
>> format (CNT, sl1l2, and vl1l2). When I look at the result .stat
file
>> (attached) I am assuming it is saying there are only three stations
that it
>> is getting obs from? If thats the case then I’m not sure the
evaluation is
>> worth the additional effort but I am confused as there should be
many more
>> station as it is maids mesonet data. I attached a log of my point
stat and
>> maids conversion if that helps.
>>
>> Also I was curious if you had a possible fix to get RH to work when
I am
>> using point stat ( its in the RH error log). I could be wrong but I
am
>> fairly certain the P_interp properly pulled the field out I just
don’t know
>> what the fourth argument is supposed to be. Also if it helps I can
shoot
>> you my config scripts for each one, Thanks!
>>
>>
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79384] Resolved: Point Stat help
From: dawsonmattg at gmail.com
Time: Tue Feb 28 18:43:31 2017
Sorry, disregard my last email, I’m an idiot… I just realized
pcp_combine counts backwards not forwards from the valid_time. Also
using RH in my script works perfect thanks again!
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 28, 2017, at 7:45 PM, Matthew Dawson <dawsonmattg at gmail.com>
wrote:
>
> John,
>
> Phew! I was getting the 3 locations for looking at the .stat file
since for there were only 3 lines for tmp, 3 lines for u, and 3 lines
for v. I wasn’t sure if the matched pairs were the obs locations or if
looking at the .stat number of lines for each variable indicated the
observations.
>
> I’ll give the the RH value a shot, but was also curious if I need
to be doing anything special other than comparing u and v fields to
get wind direction. When looking through the MET manual it seems like
to get wind direction stats you just use a variant of grid stat at the
end (a.k.a. not something I need to define in point stat).
>
> Lastly I’m hoping you maybe have a solution to the issue I am
running into when using pcp_combine for precip accumulation on stage
IV data. My issue is that I want to add up all the 1hr accumulations
over a time span of 23 hours which spans over 2 days (DD_HH) 12_06Z-
13_05Z. So while I am asking for a 23 hour accumulation, I can’t
figure out a way to change the day once it reaches the 23rd hour so
that it looks at the next days 00Z (see pcp_combine, and acclog
files). I saw the add/subtract ability in pcp_combine, which for the
observation side wouldn’t be too bad, but to try do this for 12 model
runs with the added issue of changing the initialization times would
be a bit too time consuming.
>
> I would think there could be a work around maybe by putting an if
statement in a loop somehow?
>
> <acclog><pcp_combine.sh>
>
> Anyways sorry for the constant pestering, but I at least I have
loops now to run through the point stat process for all my data so
getting closer to getting results so thanks again!
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
>> On Feb 28, 2017, at 6:20 PM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>>
>> Matt,
>>
>> I see you have some questions about the output of Point-Stat.
Thanks for
>> sending some data for me to look at.
>>
>> First, here's line number 32 of the "pointlog" that you sent to me:
>> DEBUG 2: Processing T2(0,*,*) versus TMP/Z2, for observation type
>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 126
>> pairs.
>>
>> This is telling you that the statistics for 2-m temperature were
computed
>> using 126 matched pairs. Further down, the log file tells you that
it used
>> 128 pairs for the U and V components of wind. These numbers also
show up
>> in the TOTAL column of the ".stat" file you sent to me. Look at
the column
>> right after the "LINE_TYPE" column.
>>
>> I have no idea why you're assuming it's only getting observations
from 3
>> locations.
>>
>> If you want to see that individual matched pair values, including
the
>> station location and times, just turn on the MPR output line type
in the
>> Point-Stat output_flag configuration file option. And try setting
it to
>> "BOTH" so that it creates an output file named
"point_stat*_mpr.txt".
>> That'll include a nice header row to make the data easier to read.
>>
>> Next, please try running Point-Stat at verbosity level 3 (i.e. -v
3).
>> That'll dump out the following type of log messages for each
verification
>> task:
>> DEBUG 3: Number of matched pairs = 155
>> DEBUG 3: Observations processed = 89893
>> DEBUG 3: Rejected: SID exclusion = 0
>> DEBUG 3: Rejected: GRIB code = 79360
>> DEBUG 3: Rejected: valid time = 0
>> DEBUG 3: Rejected: bad obs value = 0
>> DEBUG 3: Rejected: off the grid = 5
>> DEBUG 3: Rejected: level mismatch = 9607
>> DEBUG 3: Rejected: quality marker = 0
>> DEBUG 3: Rejected: message type = 344
>> DEBUG 3: Rejected: masking region = 422
>> DEBUG 3: Rejected: bad fcst value = 0
>> DEBUG 3: Rejected: duplicates = 0
>>
>> This tells you the number of matched pairs found for that task and
also
>> lists counts of reasons *why* the other observations were not used
for this
>> task. I find this info very helpful.
>>
>> As for the RH error, the pinterp output likely contains RH for
every model
>> level. That's what the 4th dimension is for. Use 'ncdump -h' to
look at
>> the pinterp variable:
>> float RH(Time, num_metgrid_levels, south_north, west_east) ;
>>
>> I assume you want to evaluate RH at the surface. Looks like that
isn't
>> included directly in the WRF (and thus pinterp) output. You have
two
>> choices.
>> - You could just compare the first model level to surface
observations
>> using:
>> name = "RH"; level = "(0,0,*,*)";
>> - Since WRF is "terrain-following" perhaps that's close enough. If
not,
>> you could post-process your WRF output using UPP instead of
pinterp. I'm
>> guessing UPP can be configurable to write out RH at the surface.
>>
>> Hope that helps clarify.
>>
>> Thanks,
>> John
>>
>>
>>
>> On Mon, Feb 27, 2017 at 7:41 PM, dawsonmattg at gmail.com via RT <
>> met_help at ucar.edu> wrote:
>>
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>>>
>>> John,
>>>
>>> So I have been working on trying to get everything up and running
but I’m
>>> still having some issues.
>>>
>>> I use madis2nc to convert my files into the appropriate format.
>From that
>>> I use the point_stat to evaluate the results producing the
applicable
>>> format (CNT, sl1l2, and vl1l2). When I look at the result .stat
file
>>> (attached) I am assuming it is saying there are only three
stations that it
>>> is getting obs from? If thats the case then I’m not sure the
evaluation is
>>> worth the additional effort but I am confused as there should be
many more
>>> station as it is maids mesonet data. I attached a log of my point
stat and
>>> maids conversion if that helps.
>>>
>>> Also I was curious if you had a possible fix to get RH to work
when I am
>>> using point stat ( its in the RH error log). I could be wrong but
I am
>>> fairly certain the P_interp properly pulled the field out I just
don’t know
>>> what the fourth argument is supposed to be. Also if it helps I can
shoot
>>> you my config scripts for each one, Thanks!
>>>
>>>
>>>
>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #79384] Resolved: Point Stat help
From: dawsonmattg at gmail.com
Time: Tue Feb 28 18:44:23 2017
Hey John,
Also just realized that I am not calculating wind direction (which i
need). Reading through the manual though it sounds like it isn’t
something that is derived in point stat, but from the STAT tool itself
(aggregate stat)?
Matthew G. Dawson, Capt, USAF
AFIT Student, Civilian Institution Program
Email: Dawsonmattg at gmail.com
Cell: (904)-333-5427
> On Feb 27, 2017, at 9:40 PM, Matthew Dawson <dawsonmattg at gmail.com>
wrote:
>
> John,
>
> So I have been working on trying to get everything up and running
but I’m still having some issues.
>
> I use madis2nc to convert my files into the appropriate format. From
that I use the point_stat to evaluate the results producing the
applicable format (CNT, sl1l2, and vl1l2). When I look at the result
.stat file (attached) I am assuming it is saying there are only three
stations that it is getting obs from? If thats the case then I’m not
sure the evaluation is worth the additional effort but I am confused
as there should be many more station as it is maids mesonet data. I
attached a log of my point stat and maids conversion if that helps.
>
> Also I was curious if you had a possible fix to get RH to work when
I am using point stat ( its in the RH error log). I could be wrong but
I am fairly certain the P_interp properly pulled the field out I just
don’t know what the fourth argument is supposed to be. Also if it
helps I can shoot you my config scripts for each one, Thanks!
>
> <rh_error_log>
>
> <point_stat_140000L_20160812_200000V.stat><madislog><pointlog>
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
>> On Feb 22, 2017, at 11:32 AM, John Halley Gotway via RT
<met_help at ucar.edu> wrote:
>>
>> Matthew,
>>
>> Sounds like an interesting project. Yes, the MET tools can be used
to
>> perform the individual comparisons, but there remains a lot of work
to be
>> done to script up the calls to them in the right order to
accomplish your
>> task.
>>
>> I've done a lot of that type of work using PERL and shell scripts
(mostly
>> ksh). I think we've gotten to the point in the development of the
MET
>> software, that setting up the controlling scripts is the biggest
hurdle to
>> using the software. In the last few months we've begun work on a
system
>> we're calling MET+ which is a set of python wrapper scripts for the
MET
>> tools to "automate" this scripting as much as possible. This work
is
>> driven mainly by the needs of the operational modelling community.
But
>> hopefully, a user, like yourself, would be able to set up a
configuration
>> script which the python wrapper scripts use to call the MET tools
in the
>> right order. But that's down the road. For now, you're stuck
doing it
>> yourself using whatever scripting language you prefer.
>>
>> It sounds like you're interested in continuous statistics (ME,
RMSE) for
>> surface variables and categorical stats (MODE objects and maybe
ETS) for
>> precip. You'd ultimately use Point-Stat for surface point-based
>> verification, Grid-Stat for categorical verification of precip, and
MODE
>> for an object-based evaluation of precip. While you could run
Point-Stat
>> for every 15 minute output, that may be overkill. I'd suggest
doing it
>> hourly, unless there's a good reason to do it more often.
>>
>> You run Point-Stat, Grid-Stat, and MODE once for each combination
of model
>> and output time. So you'll do many runs of those tools. From
Point-Stat,
>> you want the CNT line type (continuous stats) as well as the SL1L2
and
>> VL1L2 line types (scalar and vector parial sums) which can be
aggregated
>> later. You could consider dumping the individual matched pair
values (MPR
>> line type) but that can get to be a lot of data very quickly. From
>> Grid-Stat, you want the CTC and CTS line type (contingency table
counts and
>> statistics). Prior to running Point-Stat, you'd run PB2NC to pre-
process
>> PREPBUFR point observations. And prior to running Grid-Stat or
MODE you
>> may need to run pcp_combine if you need to change the accumulation
>> intervals of your precip data. Lastly, the STAT-Analysis tool is
used to
>> read the output of Point-Stat and Grid-Stat and accumulate
statistics over
>> the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
>> lines from each run and derive aggregated statistics. Similarly,
it can be
>> used to aggregate CTC lines from each run and derive aggregated
categorical
>> statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
(FBIAS).
>>
>> So lots of little steps to accomplish, but once you get the calls
scripted
>> up, hopefully it'll go smoothly for you.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>> On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
>> met_help at ucar.edu> wrote:
>>
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>>>
>>> John,
>>>
>>> Thanks for all the good info! Heres a little scoop on what I am
trying to
>>> accomplish if your interested, if not I have answers to your
questions
>>> starting at **********
>>>
>>> You might be familiar with the AMU (Applied Meteorology Unit
>>> https://science.ksc.nasa.gov/amu/history.html <
>>> https://science.ksc.nasa.gov/amu/history.html>) that is down in
cape
>>> canaveral. They were tasked with setting up a mesoscale model to
improve
>>> operational forecast, and ran a few different verification
statistics (ME,
>>> RMSE, MODE) on a number of different configurations your
interested here a
>>> link to their first Technical Report (Watson_2013-https://ntrs.
>>> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
>>> jsp?R=20150000384> ). Several changes have occurred over the past
few
>>> years included triple nested model as opposed to double nested,
smaller
>>> grid space, and a myriad of additional observations/assimilated
data sets
>>> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
>>> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
>>> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
>>> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
>>>
>>> Talking with the head civilian down their, lightning delays are
their
>>> primary problem, as well as forecasting convection in SE flow. So
after
>>> reading up on their configuration it seemed like using a more up
to date
>>> Microphysical model would produce better precipitation statistics
and a
>>> better overall approximation of developing convection. So I used 3
>>> different microphysics schemes to create 12 different model runs,
which
>>> show some reasonable difference when plotting rain totals ect.
>>>
>>> ************
>>> So with the 12 different models I am trying to create a
“scorecard” to
>>> show which ones more accurately predicted the surface
precipitation, wind
>>> speed, direction, T, Td.
>>>
>>> The week of model runs were purposely selected over a period
predominantly
>>> SE flow (august) which they have trouble forecasting for. This is
somewhat
>>> of a sub-regime in their overall summertime regime, but since most
>>> convection is characterized by mesoscale process (sea-breeze,
river-breeze)
>>> it could be extended for the entire summer months. The model was
PRIMARY
>>> developed to help summertime forecast as lightning delays cost
them lots of
>>> $$$, so I’m not even sure if they rely on this model, as opposed
to some of
>>> the national centers, during other seasons.
>>>
>>> Since the prior work from the above papers used ME, RMSE in the
point stat
>>> tool and MODE for precip I want to try use the same techniques.
>>>
>>> I guess my real question would be how I should go about setting
everything
>>> up, coding.
>>>
>>> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
>>> (precip) values for each day and for the total week. Since my wrf
outfiles
>>> are in 15 min intervals, over 24 hours I’m not sure how to specify
in point
>>> stat how to read in all these files and produce one RMSE and ME
value for
>>> the day, or produce them for each time and them calculate the
total for the
>>> day. I’m not sure if I need to somehow mesh all my wrfout files
into one
>>> file and then have point stat use that or if there is a simpler
way.
>>>
>>>
>>> Matthew G. Dawson, Capt, USAF
>>> AFIT Student, Civilian Institution Program
>>> Email: Dawsonmattg at gmail.com
>>> Cell: (904)-333-5427
>>>
>>>> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
>>> met_help at ucar.edu> wrote:
>>>>
>>>> Matthew,
>>>>
>>>> Great, I'm glad you were able to get it up and running!
>>>>
>>>> There's no need to acknowledge me directly, but I'd appreciate
you
>>>> acknowledging the MET software package. The more advertising we
can get
>>>> for future funding, the better!
>>>>
>>>> As for your choice of verification datasets, that's usually
limited by
>>> your
>>>> domain, the timing of your model output, and the actual
verification
>>>> questions you're trying to answer. With output from 12 different
models,
>>>> what are you actually trying to assess? Is it just a scorecard
to see
>>>> which model verifies better overall? Or do you have more
specific
>>>> questions? With only one week of data to compare, you can do an
>>> objective
>>>> comparison... but will your results hold up during the other 3
seasons?
>>> Or
>>>> during other weather regimes? So I'd be hesitant in using only
one week
>>> of
>>>> data to make strong claims about overall performance.
>>>>
>>>> With data every 15 minutes, I believe that the surface data shows
up
>>> pretty
>>>> in PREPBUFR pretty regularly. So you could do surface
verification up to
>>>> every 15 minutes if you'd like. While there are a very small
number of
>>>> soundings in PREPBUFR files at off-hours, we generally only
verify
>>>> upper-air at 00Z and 12Z.
>>>>
>>>> For choice of precipitation analysis... I'd suggest reading about
>>> StageII,
>>>> StageIV, CCPA, and MRMS. We've used all of them on different
projects
>>>> within the DTC. MRMS is probably the one being most actively
worked on
>>>> right now. Depending on what questions you're asking, you could
also
>>>> compare against URMA which is a gridded CONUS analysis product.
>>>>
>>>> Let me warn you that I'm a software engineer, not a statistician
or
>>>> atmospheric scientist. But we do have both of them on the MET
team. So
>>> if
>>>> you have specific questions in those areas, I could route them to
the
>>> right
>>>> person.
>>>>
>>>> Hope that helps.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com <mailto:
>>> dawsonmattg at gmail.com> via RT <
>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
>>>>
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
>>>>>
>>>>> Hey John,
>>>>>
>>>>> Sorry for the late reply, but your suggestion worked! I
also
>>>>> figured out I was referencing the wrong file time which of
course would
>>>>> come back with no results.
>>>>>
>>>>> I was curious though how you would suggest tackling my
“project".
>>>>> I have 12 different model outputs (the same domain) over the
same week
>>> that
>>>>> I want to try verify. The model output occurs at 15 min
intervals, and
>>> I am
>>>>> primary interested in precipitation skill scores (would like to
use the
>>>>> MODE tool), but the temperature, Td, wind speed and direction
will also
>>> be
>>>>> useful. I was planing on using the MODE tool to evaluate the SFC
precip
>>> to
>>>>> stage II radar data unless you would recommend another way. Also
please
>>> let
>>>>> me know if you would like me to add you in my acknowledgement
section
>>> for
>>>>> help with this tool kit, thanks!
>>>>>
>>>>> Matthew G. Dawson, Capt, USAF
>>>>> AFIT Student, Civilian Institution Program
>>>>> Email: Dawsonmattg at gmail.com
>>>>> Cell: (904)-333-5427
>>>>>
>>>>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
>>>>> met_help at ucar.edu> wrote:
>>>>>>
>>>>>> According to our records, your request has been resolved. If
you have
>>> any
>>>>>> further questions or concerns, please respond to this message.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
>>> met_help at ucar.edu
>>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
>>>>>
>>>>> Matthew,
>>>>>
>>>>> The verification of surface variables is done in a pretty
simplistic
>>> way by
>>>>> specifying the message type.
>>>>>
>>>>> The ADPSFC and SFCSHP message types are assumed to exist at the
surface
>>> and
>>>>> are used to verifying "surface" variables such as 2m temperature
and
>>> 10-m
>>>>> winds. And ONLYSF is a short-cut for combining land-based
ADPSFC and
>>>>> water-based SFCSHP observations together. Your Point-Stat
config file
>>>>> should look something like this:
>>>>>
>>>>> fcst = {
>>>>> field = [
>>>>> {
>>>>> name = "T2";
>>>>> level = [ "(*,*,0)" ];
>>>>> cat_thresh = [ <=273, >273 ];
>>>>> }
>>>>> ];
>>>>> }
>>>>>
>>>>> obs = {
>>>>> message_type = [ "ADPSFC" ];
>>>>> sid_exc = [];
>>>>>
>>>>> field = [
>>>>> {
>>>>> name = "TMP";
>>>>> level = [ "Z2" ];
>>>>> cat_thresh = [ <=273, >273 ];
>>>>> }
>>>>> ];
>>>>> }
>>>>>
>>>>> Does that produce any matched pairs? I don't see the source of
the
>>>>> PREPBUFR observation data you're using, but if you're using
GDAS, please
>>>>> read the NOTE at the bottom of this page about the quality
marker that's
>>>>> assigned to surface observations:
>>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>>> http://www.dtcenter.org/met/users/downloads/observation_data.php>
<
>>>>> http://www.dtcenter.org/met/users/downloads/observation_data.php
<
>>> http://www.dtcenter.org/met/users/downloads/observation_data.php>>
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
>>> dawsonmattg at gmail.com> <mailto:
>>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>>> wrote:
>>>>>
>>>>>>
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>>
>>>>>> John,
>>>>>>
>>>>>> Thanks for the reply! I originally wanted to use UPP, but the
cluster I
>>>>> ran
>>>>>> my WRF models on didn’t have much space (very fast though) so I
had to
>>>>>> offload all my data to another cluster my professor uses which
isn’t
>>> very
>>>>>> fast but has plenty of space. Since UPP has to have a path to
my WRF
>>>>> build
>>>>>> (excerpt below), I decided it was not feasible.
>>>>>>
>>>>>> "Overview of the scripts to run the UPP Note: It is recommended
that
>>> the
>>>>>> user refer to the run_unipost* scripts in the script/ while
reading
>>> this
>>>>>> overview.
>>>>>> 1. Set up variables:
>>>>>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
>>>>>> DOMAINPATH: directory where UPP will be run from
>>>>>> WRFPATH: path to your WRFV3 build; defaults to the environment
variable
>>>>>> used during the installation with the configure script
>>>>>> UNI_POST_HOME: path to your UPPV2.1 build
>>>>>> POSTEXEC: path to your UPPV2.1 executables”
>>>>>>
>>>>>> As for the winds, my WRF output does supply 10 meter winds,
which I
>>> would
>>>>>> assume P_Interp would just put at the level (0,*,*), so in the
case
>>>>>> shouldn't I be able to verify winds as well?
>>>>>>
>>>>>> Anyways I tried your fix and while it does run I'm not actually
getting
>>>>> any
>>>>>> values. I'm fairly certain its because I specified the Level
for the
>>> obs
>>>>>> at, "P1000". I'm not sure how to specify the level as the
"surface" or
>>> 10
>>>>>> meters though.
>>>>>>
>>>>>> DEBUG 2:
>>>>>> ------------------------------------------------------------
>>>>>> --------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Reading data for T2(0,*,*).
>>>>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0
climatology
>>> levels.
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>> ------------------------------------------------------------
>>>>>> --------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Searching 41979 observations from 6956 messages.
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>> ------------------------------------------------------------
>>>>>> --------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPUPA, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPSFC, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> ADPSFC, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> MSONET, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> MSONET, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> SRFSHP, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> SRFSHP, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> VADWND, over region FULL, for interpolation method NEAREST(1),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for observation
type
>>>>>> VADWND, over region FULL, for interpolation method DW_MEAN(9),
using 0
>>>>>> pairs.
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>> ------------------------------------------------------------
>>>>>> --------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
>>>>>> DEBUG 1: Output file:
>>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
>>>>>> DEBUG 1: Output file:
>>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
>>>>>> DEBUG 1: Output file:
>>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
>>>>>> DEBUG 1: Output file:
>>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
>>>>>> DEBUG 1: Output file:
>>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Matthew G. Dawson, Capt, USAF
>>>>>> AFIT Student, Civilian Institution Program
>>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>>
>>>>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
>>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
>>>>>> wrote:
>>>>>>
>>>>>> Matthew,
>>>>>>
>>>>>> I see that you have some questions about running the Point-Stat
tool.
>>>>>>
>>>>>> Regarding post-processing, I'd suggest switching from the
pinterp
>>> utility
>>>>>> to using the Unified Post-Processor (UPP). It writes output in
GRIB
>>>>> which
>>>>>> MET can easily handle. Why pinterp output could work fine for
precip,
>>>>>> temperature, and dewpoint, MET won't be able to process the
winds since
>>>>>> they're defined on the staggered dimension. I realize that
running
>>> UPP,
>>>>>> yet another tool to compile and script up, can be a hassle.
But I
>>> think
>>>>>> it'll be less work in the long run.
>>>>>>
>>>>>> But as for your specific error from Point-Stat, I suspect
that'll be
>>> easy
>>>>>> to fix. In your Point-Stat config file, try using:
>>>>>> name = "T2";
>>>>>> level = [ "(0,*,*)" ];
>>>>>>
>>>>>> I often like plotting the data first:
>>>>>> met-5.2/bin/plot_data_plane \
>>>>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
>>>>>> d01_2016-08-12_12:00:00_PLEV
>>>>>> \
>>>>>> T2.ps \
>>>>>> 'name="T2"; level="(0,*,*)";'
>>>>>>
>>>>>> Hopefully that'll create a PostScript plot of your data.
>>>>>>
>>>>>> Thanks,
>>>>>> John Halley Gotway
>>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com <mailto:
>>> dawsonmattg at gmail.com> <mailto:
>>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
>>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu>
<mailto:met_help at ucar.edu
>>> <mailto:met_help at ucar.edu>>> wrote:
>>>>>>
>>>>>>
>>>>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
>>>>>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
>>> dawsonmattg at gmail.com> <mailto:
>>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>>> Queue: met_help
>>>>>> Subject: Point Stat help
>>>>>> Owner: Nobody
>>>>>> Requestors: dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com>
>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>>> Status: new
>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
>>>>>>
>>>>>>
>>>>>> Hello MET help,
>>>>>>
>>>>>> I’m going to go ahead and apologize for all the information
in
>>>>>> this email, but hopefully it will help you better diagnose what
the
>>> best
>>>>>> way for me to move forward is. As part of my research I
generated 12
>>>>>> different WRF runs over the same week using the same I.C.s and
B.C.s,
>>> and
>>>>>> am currently in the process of comparing them against real
world
>>>>>> observations to see which config worked the best. I am primary
>>> concerned
>>>>>> with comparing precip, surface temp/dewpoint, and surface
winds.
>>>>>>
>>>>>> The first tool I have tried to use has been the point stat
tool. I
>>>>>> am using your met-5.2_bugfix package and did not find any
errors
>>>>>> while/after compiling and made sure the test files, like
>>>>>> test_point_stat.sh, all work. The data I am using is as
follows:
>>>>>>
>>>>>>
>>>>>> Instead of downloading prepbufer files and
converting them
>>>>>> with the PB2NC tool, I just used the UCAR site to do it for me
(
>>>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su <
>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
>>>>> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
>>> http://rda.ucar.edu/datasets/>
>>>>> ds337.0/index.html#forms/337_subset.php?_da=y>
>>>>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
>>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
>>>>>> subset.php?_da=y>)
>>>>>> Request Detail:
>>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>>> NCEP Verification Regions : SEC
>>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>>> PRMSL
>>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>>> Quality Mark Threshold : 9
>>>>>> File Compression : gz
>>>>>> Data Output Format : NETCDF
>>>>>>
>>>>>>
>>>>>>
>>>>>> To convert my WRF data into a readable format I used
P_Interp. I
>>>>>> am now realizing this might not be the best way forward, but
seemed the
>>>>>> easiest to set up as I had to offload all my model output to a
>>> different
>>>>>> cluster that I did not configure WRF on. I have been a bit
confused as
>>>>>> P_Interp says it can unstager data to pressure levels, but on
your
>>>>> website
>>>>>> it says that P_Interp cannot onstager data (at least for use
with MODE
>>>>> and
>>>>>> other tools). Either way do you think I should try use a
different
>>>>>> pre-processing software to unpack my WRF data or will P_Interp
be
>>>>>> sufficient to compare precip, surface temp/dewpoint and winds?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> When I run my file PointStat.sh using the attached
>>>>>> PointStatConfig1 file, I get the following data error message:
>>>>>>
>>>>>> *** Running Point-Stat on prepbuffer files ***
>>>>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
>>>>>> bugfix/share/met/config/PointStatConfig_default
>>>>>> DEBUG 1: User Config File: config/PointStatConfig
>>>>>> GSL_RNG_TYPE=mt19937
>>>>>> GSL_RNG_SEED=1
>>>>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
>>>>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
>>>>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
>>>>>> .gdas.225564.2016081200.nc
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
------------------------------------------------------------
>>>>>> --------------------
>>>>>> DEBUG 2:
>>>>>> DEBUG 2: Reading data for T2(*,*,0).
>>>>>> WARNING:
>>>>>> WARNING: PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
>>>>> double
>>>>>> &) const -> star found in bad slot
>>>>>> WARNING:
>>>>>> ERROR :
>>>>>> ERROR : PinterpFile::valid_time(int) const -> range check
error
>>>>>> ERROR :
>>>>>>
>>>>>>
>>>>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
>>>>>> float T2(Time, south_north, west_east) ;
>>>>>> T2:FieldType = 104 ;
>>>>>> T2:MemoryOrder = "XY " ;
>>>>>> T2:description = "TEMP at 2 M" ;
>>>>>> T2:units = "K" ;
>>>>>> T2:stagger = "" ;
>>>>>> T2:coordinates = "XLONG XLAT XTIME" ;
>>>>>> T2:missing_value = 1.e+36f ;
>>>>>>
>>>>>> I am not sure if the issue is that P_Interp is not properly
extracting
>>>>>> this information, or If I just need to change my
PointStatConfig1 file.
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> Matthew G. Dawson, Capt, USAF
>>>>>> AFIT Student, Civilian Institution Program
>>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
>>>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
>>>>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
>>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>>>>
>>>>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
>>> tcram at ucar.edu> <mailto:
>>>>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
>>>>>>
>>>>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:
>>> tcram at ucar.edu>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> I recommend contacting MET support (cc'd here). It's possible
you
>>>>>>
>>>>>> should be using the PrepBUFR data instead of the NetCDF data in
MET,
>>> but
>>>>>> having no experience using MET, I am merely speculating on
this. MET
>>>>>> support should be able to help you out.
>>>>>>
>>>>>>
>>>>>> Good luck,
>>>>>> - Tom
>>>>>>
>>>>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew
<dawsonmattg at gmail.com
>>> <mailto:dawsonmattg at gmail.com>
>>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
>>>>>>
>>>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
<mailto:
>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
>>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
>>>>>>
>>>>>> Hey Thomas
>>>>>>
>>>>>> I was able to get the data download with no issues, however I
have been
>>>>>>
>>>>>> having issues with actually using that data in MET. I am trying
to
>>>>> compare
>>>>>> it to some WRF output (used P-Interp to convert into a MET
readable
>>>>>> format), but the PointStatConfig file keeps having issues (I’m
not
>>> sure I
>>>>>> filled it out correctly). Anyways I was wondering if you, or
anyone
>>>>>> happened to know of an online resource, or even someone who had
a
>>>>>> configuration set up for comparing data against WRF data so I
can
>>> compare
>>>>>> what I have against there config files and hopefully figure out
where I
>>>>> am
>>>>>> going wrong. I’ve been looking through the MET user guide but
haven’t
>>>>> found
>>>>>> a solution yet. Thanks!
>>>>>>
>>>>>>
>>>>>> Matthew G. Dawson, Capt, USAF
>>>>>> AFIT Student, Civilian Institution Program
>>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
>>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
>>> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
>>> <mailto:
>>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
>>>>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-5427
>>> <tel:%28904%29-333-5427>
>>>>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
>>>>>> <%28904%29-333-5427>>
>>>>>>
>>>>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
>>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>>> <mailto:tcram at ucar.edu>>
>>>>>> <tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
>>> <mailto:tcram at ucar.edu>>>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Your subset request for NCEP ADP Global Upper Air and Surface
Weather
>>>>>>
>>>>>> Observations has completed.
>>>>>>
>>>>>> Please login to the NCAR RDA server at http://rda.ucar.edu <
>>> http://rda.ucar.edu/> <
>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
>>>>>>
>>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
>>> http://rda.ucar.edu/>>>, then download your files
>>>>> from the
>>>>>>
>>>>>> following URL:
>>>>>>
>>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>>> <http://rda.ucar.edu/#dsrqst/D>
>>>>> AWSON225564/> <
>>>>>>
>>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/>
<http://rda.ucar.edu/#dsrqst/D
>>> <http://rda.ucar.edu/#dsrqst/D>
>>>>> AWSON225564/>>
>>>>>>
>>>>>>
>>>>>> Request ID: DAWSON225564
>>>>>>
>>>>>> Request Detail:
>>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
>>>>>> NCEP Verification Regions : SEC
>>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND RH
MIXR
>>>>>>
>>>>>> PRMSL
>>>>>>
>>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI AIRCFT
QKSWND
>>>>>>
>>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
>>>>>>
>>>>>> Quality Mark Threshold : 9
>>>>>> File Compression : gz
>>>>>> Data Output Format : NETCDF
>>>>>>
>>>>>>
>>>>>> The "rda-request-manager" command line tool provides an
additional
>>>>>>
>>>>>> option for users to download
>>>>>>
>>>>>> request output files on unix based systems. The "rda-request-
manager"
>>>>>>
>>>>>> tool can be accessed at:
>>>>>>
>>>>>>
>>>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
>>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
>>>>>>
>>>>>> The data provided in your data request are a subset of the NCAR
RDA
>>>>>>
>>>>>> dataset ds337.0 --
>>>>>>
>>>>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
(PREPBUFR
>>>>>>
>>>>>> format), May 1997 - Continuing'. Please see
>>>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/> <
>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
>>>>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
>>> http://rda.ucar.edu/datasets/ds337.0/> <
>>>>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
>>> ds337.0/>>> for more information.
>>>>>>
>>>>>>
>>>>>> Your data will remain on our system for 5 days. If this is not
>>>>>>
>>>>>> sufficient time for you to retrieve
>>>>>>
>>>>>> your data, please let me know as soon as possible, so that I
can
>>>>>>
>>>>>> prevent the data files from being
>>>>>>
>>>>>> purged too soon.
>>>>>>
>>>>>> If you have any questions related to this data request, please
let me
>>>>>>
>>>>>> know by replying to this
>>>>>>
>>>>>> email.
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> Thomas Cram
>>>>>> NCAR/CISL/Data Support Section
>>>>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-
1217
>>> <tel:%28303%29-497-1217>
>>>>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
>>>>>> <%28303%29-497-1217>>
>>>>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/
>>> <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Cram
>>>>>> NCAR / CISL / DSS
>>>>>> tel: +1-303-497-1217 <(303)%20497-1217>
>>>>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
>>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>
>>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>> <tcram at ucar.edu
>>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu>>>>
>>>>>> web: rda.ucar.edu <http://rda.ucar.edu/> <http://rda.ucar.edu/
<
>>> http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
>>>>>>
>>>>>>
>>>>>> Matthew G. Dawson, Capt, USAF
>>>>>> AFIT Student, Civilian Institution Program
>>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
>>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
>>>
>>>
>>>
>>
>
------------------------------------------------
Subject: Point Stat help
From: John Halley Gotway
Time: Wed Mar 01 21:18:41 2017
Matt,
The MET tools don't read the output of WRF directly and instead
require
that it first be post-processed. Your post-processing options are the
p_interp (or newer wrf_interp) utility for WRF-ARW or the Unified Post
Processor (UPP) for both WRF-ARW and WRF-NMM. We recommend using UPP
which
has the ability to compute several derived fields and regrid to
whatever
domain you'd like.
While MET can read the NetCDF output of p_interp, it only handle
variable
defined on the non-staggered dimension. So MET reads data from the
"mass
points" but not the velocity points... which is exactly where the
winds are
defined.
For this reason, you can't really use MET to verify winds from
p_interp
files. So what to do?
- You could "hack" your data or the MET code to basically tell it to
pretend like winds are defined at the mass points rather than the
velocity
points. That may or may not work... but will certainly introduce
small
interpolation errors.
- You could switch to post-processing with UPP. There is a similar
helpdesk (upp-help at ucar.edu) through which the DTC and NCAR provide
support
for its compilation and use.
Hopefully that helps clarify.
Thanks,
John
On Tue, Feb 28, 2017 at 6:44 PM, dawsonmattg at gmail.com via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
>
> Hey John,
>
> Also just realized that I am not calculating wind direction
(which
> i need). Reading through the manual though it sounds like it isn’t
> something that is derived in point stat, but from the STAT tool
itself
> (aggregate stat)?
>
> Matthew G. Dawson, Capt, USAF
> AFIT Student, Civilian Institution Program
> Email: Dawsonmattg at gmail.com
> Cell: (904)-333-5427
>
> > On Feb 27, 2017, at 9:40 PM, Matthew Dawson
<dawsonmattg at gmail.com>
> wrote:
> >
> > John,
> >
> > So I have been working on trying to get everything up and running
but
> I’m still having some issues.
> >
> > I use madis2nc to convert my files into the appropriate format.
From
> that I use the point_stat to evaluate the results producing the
applicable
> format (CNT, sl1l2, and vl1l2). When I look at the result .stat file
> (attached) I am assuming it is saying there are only three stations
that it
> is getting obs from? If thats the case then I’m not sure the
evaluation is
> worth the additional effort but I am confused as there should be
many more
> station as it is maids mesonet data. I attached a log of my point
stat and
> maids conversion if that helps.
> >
> > Also I was curious if you had a possible fix to get RH to work
when I am
> using point stat ( its in the RH error log). I could be wrong but I
am
> fairly certain the P_interp properly pulled the field out I just
don’t know
> what the fourth argument is supposed to be. Also if it helps I can
shoot
> you my config scripts for each one, Thanks!
> >
> > <rh_error_log>
> >
> > <point_stat_140000L_20160812_200000V.stat><madislog><pointlog>
> >
> > Matthew G. Dawson, Capt, USAF
> > AFIT Student, Civilian Institution Program
> > Email: Dawsonmattg at gmail.com
> > Cell: (904)-333-5427
> >
> >> On Feb 22, 2017, at 11:32 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
> >>
> >> Matthew,
> >>
> >> Sounds like an interesting project. Yes, the MET tools can be
used to
> >> perform the individual comparisons, but there remains a lot of
work to
> be
> >> done to script up the calls to them in the right order to
accomplish
> your
> >> task.
> >>
> >> I've done a lot of that type of work using PERL and shell scripts
> (mostly
> >> ksh). I think we've gotten to the point in the development of
the MET
> >> software, that setting up the controlling scripts is the biggest
hurdle
> to
> >> using the software. In the last few months we've begun work on a
system
> >> we're calling MET+ which is a set of python wrapper scripts for
the MET
> >> tools to "automate" this scripting as much as possible. This
work is
> >> driven mainly by the needs of the operational modelling
community. But
> >> hopefully, a user, like yourself, would be able to set up a
> configuration
> >> script which the python wrapper scripts use to call the MET tools
in the
> >> right order. But that's down the road. For now, you're stuck
doing it
> >> yourself using whatever scripting language you prefer.
> >>
> >> It sounds like you're interested in continuous statistics (ME,
RMSE) for
> >> surface variables and categorical stats (MODE objects and maybe
ETS) for
> >> precip. You'd ultimately use Point-Stat for surface point-based
> >> verification, Grid-Stat for categorical verification of precip,
and MODE
> >> for an object-based evaluation of precip. While you could run
> Point-Stat
> >> for every 15 minute output, that may be overkill. I'd suggest
doing it
> >> hourly, unless there's a good reason to do it more often.
> >>
> >> You run Point-Stat, Grid-Stat, and MODE once for each combination
of
> model
> >> and output time. So you'll do many runs of those tools. From
> Point-Stat,
> >> you want the CNT line type (continuous stats) as well as the
SL1L2 and
> >> VL1L2 line types (scalar and vector parial sums) which can be
aggregated
> >> later. You could consider dumping the individual matched pair
values
> (MPR
> >> line type) but that can get to be a lot of data very quickly.
From
> >> Grid-Stat, you want the CTC and CTS line type (contingency table
counts
> and
> >> statistics). Prior to running Point-Stat, you'd run PB2NC to
> pre-process
> >> PREPBUFR point observations. And prior to running Grid-Stat or
MODE
> you
> >> may need to run pcp_combine if you need to change the
accumulation
> >> intervals of your precip data. Lastly, the STAT-Analysis tool is
used
> to
> >> read the output of Point-Stat and Grid-Stat and accumulate
statistics
> over
> >> the week. For "aggregate_stat" job type can be used to aggregate
SL1L2
> >> lines from each run and derive aggregated statistics. Similarly,
it
> can be
> >> used to aggregate CTC lines from each run and derive aggregated
> categorical
> >> statistics, like CSI, ETS (called GSS in MET), and Frequency Bias
> (FBIAS).
> >>
> >> So lots of little steps to accomplish, but once you get the calls
> scripted
> >> up, hopefully it'll go smoothly for you.
> >>
> >> Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >> On Tue, Feb 21, 2017 at 8:56 PM, dawsonmattg at gmail.com via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >>>
> >>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 >
> >>>
> >>> John,
> >>>
> >>> Thanks for all the good info! Heres a little scoop on what I am
trying
> to
> >>> accomplish if your interested, if not I have answers to your
questions
> >>> starting at **********
> >>>
> >>> You might be familiar with the AMU (Applied Meteorology Unit
> >>> https://science.ksc.nasa.gov/amu/history.html <
> >>> https://science.ksc.nasa.gov/amu/history.html>) that is down in
cape
> >>> canaveral. They were tasked with setting up a mesoscale model to
> improve
> >>> operational forecast, and ran a few different verification
statistics
> (ME,
> >>> RMSE, MODE) on a number of different configurations your
interested
> here a
> >>> link to their first Technical Report (Watson_2013-https://ntrs.
> >>> nasa.gov/search.jsp?R=20150000384 <https://ntrs.nasa.gov/search.
> >>> jsp?R=20150000384> ). Several changes have occurred over the
past few
> >>> years included triple nested model as opposed to double nested,
smaller
> >>> grid space, and a myriad of additional observations/assimilated
data
> sets
> >>> Watson_2014-https://ntrs.nasa.gov/search.jsp?R=20150000384 <
> >>> https://ntrs.nasa.gov/search.jsp?R=20150000384>, Schafer_2015-
> >>> https://ntrs.nasa.gov/search.jsp?R=20160007687 <
> >>> https://ntrs.nasa.gov/search.jsp?R=20160007687> .
> >>>
> >>> Talking with the head civilian down their, lightning delays are
their
> >>> primary problem, as well as forecasting convection in SE flow.
So after
> >>> reading up on their configuration it seemed like using a more up
to
> date
> >>> Microphysical model would produce better precipitation
statistics and a
> >>> better overall approximation of developing convection. So I used
3
> >>> different microphysics schemes to create 12 different model
runs, which
> >>> show some reasonable difference when plotting rain totals ect.
> >>>
> >>> ************
> >>> So with the 12 different models I am trying to create a
“scorecard” to
> >>> show which ones more accurately predicted the surface
precipitation,
> wind
> >>> speed, direction, T, Td.
> >>>
> >>> The week of model runs were purposely selected over a period
> predominantly
> >>> SE flow (august) which they have trouble forecasting for. This
is
> somewhat
> >>> of a sub-regime in their overall summertime regime, but since
most
> >>> convection is characterized by mesoscale process (sea-breeze,
> river-breeze)
> >>> it could be extended for the entire summer months. The model was
> PRIMARY
> >>> developed to help summertime forecast as lightning delays cost
them
> lots of
> >>> $$$, so I’m not even sure if they rely on this model, as opposed
to
> some of
> >>> the national centers, during other seasons.
> >>>
> >>> Since the prior work from the above papers used ME, RMSE in the
point
> stat
> >>> tool and MODE for precip I want to try use the same techniques.
> >>>
> >>> I guess my real question would be how I should go about setting
> everything
> >>> up, coding.
> >>>
> >>> I would like to have RMSE, ME( T, Td, wind direction, speed) and
MODE
> >>> (precip) values for each day and for the total week. Since my
wrf
> outfiles
> >>> are in 15 min intervals, over 24 hours I’m not sure how to
specify in
> point
> >>> stat how to read in all these files and produce one RMSE and ME
value
> for
> >>> the day, or produce them for each time and them calculate the
total
> for the
> >>> day. I’m not sure if I need to somehow mesh all my wrfout files
into
> one
> >>> file and then have point stat use that or if there is a simpler
way.
> >>>
> >>>
> >>> Matthew G. Dawson, Capt, USAF
> >>> AFIT Student, Civilian Institution Program
> >>> Email: Dawsonmattg at gmail.com
> >>> Cell: (904)-333-5427
> >>>
> >>>> On Feb 21, 2017, at 4:06 PM, John Halley Gotway via RT <
> >>> met_help at ucar.edu> wrote:
> >>>>
> >>>> Matthew,
> >>>>
> >>>> Great, I'm glad you were able to get it up and running!
> >>>>
> >>>> There's no need to acknowledge me directly, but I'd appreciate
you
> >>>> acknowledging the MET software package. The more advertising
we can
> get
> >>>> for future funding, the better!
> >>>>
> >>>> As for your choice of verification datasets, that's usually
limited by
> >>> your
> >>>> domain, the timing of your model output, and the actual
verification
> >>>> questions you're trying to answer. With output from 12
different
> models,
> >>>> what are you actually trying to assess? Is it just a scorecard
to see
> >>>> which model verifies better overall? Or do you have more
specific
> >>>> questions? With only one week of data to compare, you can do
an
> >>> objective
> >>>> comparison... but will your results hold up during the other 3
> seasons?
> >>> Or
> >>>> during other weather regimes? So I'd be hesitant in using only
one
> week
> >>> of
> >>>> data to make strong claims about overall performance.
> >>>>
> >>>> With data every 15 minutes, I believe that the surface data
shows up
> >>> pretty
> >>>> in PREPBUFR pretty regularly. So you could do surface
verification
> up to
> >>>> every 15 minutes if you'd like. While there are a very small
number
> of
> >>>> soundings in PREPBUFR files at off-hours, we generally only
verify
> >>>> upper-air at 00Z and 12Z.
> >>>>
> >>>> For choice of precipitation analysis... I'd suggest reading
about
> >>> StageII,
> >>>> StageIV, CCPA, and MRMS. We've used all of them on different
projects
> >>>> within the DTC. MRMS is probably the one being most actively
worked
> on
> >>>> right now. Depending on what questions you're asking, you
could also
> >>>> compare against URMA which is a gridded CONUS analysis product.
> >>>>
> >>>> Let me warn you that I'm a software engineer, not a
statistician or
> >>>> atmospheric scientist. But we do have both of them on the MET
team.
> So
> >>> if
> >>>> you have specific questions in those areas, I could route them
to the
> >>> right
> >>>> person.
> >>>>
> >>>> Hope that helps.
> >>>>
> >>>> Thanks,
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Feb 18, 2017 at 11:15 AM, dawsonmattg at gmail.com
<mailto:
> >>> dawsonmattg at gmail.com> via RT <
> >>>> met_help at ucar.edu <mailto:met_help at ucar.edu>> wrote:
> >>>>
> >>>>>
> >>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> >
> >>>>>
> >>>>> Hey John,
> >>>>>
> >>>>> Sorry for the late reply, but your suggestion worked! I
also
> >>>>> figured out I was referencing the wrong file time which of
course
> would
> >>>>> come back with no results.
> >>>>>
> >>>>> I was curious though how you would suggest tackling my
> “project".
> >>>>> I have 12 different model outputs (the same domain) over the
same
> week
> >>> that
> >>>>> I want to try verify. The model output occurs at 15 min
intervals,
> and
> >>> I am
> >>>>> primary interested in precipitation skill scores (would like
to use
> the
> >>>>> MODE tool), but the temperature, Td, wind speed and direction
will
> also
> >>> be
> >>>>> useful. I was planing on using the MODE tool to evaluate the
SFC
> precip
> >>> to
> >>>>> stage II radar data unless you would recommend another way.
Also
> please
> >>> let
> >>>>> me know if you would like me to add you in my acknowledgement
section
> >>> for
> >>>>> help with this tool kit, thanks!
> >>>>>
> >>>>> Matthew G. Dawson, Capt, USAF
> >>>>> AFIT Student, Civilian Institution Program
> >>>>> Email: Dawsonmattg at gmail.com
> >>>>> Cell: (904)-333-5427
> >>>>>
> >>>>>> On Feb 15, 2017, at 4:07 PM, John Halley Gotway via RT <
> >>>>> met_help at ucar.edu> wrote:
> >>>>>>
> >>>>>> According to our records, your request has been resolved. If
you
> have
> >>> any
> >>>>>> further questions or concerns, please respond to this
message.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Feb 8, 2017, at 7:03 PM, John Halley Gotway via RT <
> >>> met_help at ucar.edu
> >>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>> wrote:
> >>>>>
> >>>>> Matthew,
> >>>>>
> >>>>> The verification of surface variables is done in a pretty
simplistic
> >>> way by
> >>>>> specifying the message type.
> >>>>>
> >>>>> The ADPSFC and SFCSHP message types are assumed to exist at
the
> surface
> >>> and
> >>>>> are used to verifying "surface" variables such as 2m
temperature and
> >>> 10-m
> >>>>> winds. And ONLYSF is a short-cut for combining land-based
ADPSFC and
> >>>>> water-based SFCSHP observations together. Your Point-Stat
config
> file
> >>>>> should look something like this:
> >>>>>
> >>>>> fcst = {
> >>>>> field = [
> >>>>> {
> >>>>> name = "T2";
> >>>>> level = [ "(*,*,0)" ];
> >>>>> cat_thresh = [ <=273, >273 ];
> >>>>> }
> >>>>> ];
> >>>>> }
> >>>>>
> >>>>> obs = {
> >>>>> message_type = [ "ADPSFC" ];
> >>>>> sid_exc = [];
> >>>>>
> >>>>> field = [
> >>>>> {
> >>>>> name = "TMP";
> >>>>> level = [ "Z2" ];
> >>>>> cat_thresh = [ <=273, >273 ];
> >>>>> }
> >>>>> ];
> >>>>> }
> >>>>>
> >>>>> Does that produce any matched pairs? I don't see the source
of the
> >>>>> PREPBUFR observation data you're using, but if you're using
GDAS,
> please
> >>>>> read the NOTE at the bottom of this page about the quality
marker
> that's
> >>>>> assigned to surface observations:
> >>>>>
http://www.dtcenter.org/met/users/downloads/observation_data.php <
> >>>
http://www.dtcenter.org/met/users/downloads/observation_data.php> <
> >>>>>
http://www.dtcenter.org/met/users/downloads/observation_data.php <
> >>>
http://www.dtcenter.org/met/users/downloads/observation_data.php>>
> >>>>>
> >>>>> Thanks,
> >>>>> John
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> John
> >>>>>
> >>>>> On Wed, Feb 8, 2017 at 4:50 PM, dawsonmattg at gmail.com <mailto:
> >>> dawsonmattg at gmail.com> <mailto:
> >>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >>>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >>> <mailto:met_help at ucar.edu>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384
<
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>>>>
> >>>>>> John,
> >>>>>>
> >>>>>> Thanks for the reply! I originally wanted to use UPP, but the
> cluster I
> >>>>> ran
> >>>>>> my WRF models on didn’t have much space (very fast though) so
I had
> to
> >>>>>> offload all my data to another cluster my professor uses
which isn’t
> >>> very
> >>>>>> fast but has plenty of space. Since UPP has to have a path to
my WRF
> >>>>> build
> >>>>>> (excerpt below), I decided it was not feasible.
> >>>>>>
> >>>>>> "Overview of the scripts to run the UPP Note: It is
recommended that
> >>> the
> >>>>>> user refer to the run_unipost* scripts in the script/ while
reading
> >>> this
> >>>>>> overview.
> >>>>>> 1. Set up variables:
> >>>>>> TOP_DIR: top level directory for source codes (UPPV2.1 and
WRFV3)
> >>>>>> DOMAINPATH: directory where UPP will be run from
> >>>>>> WRFPATH: path to your WRFV3 build; defaults to the
environment
> variable
> >>>>>> used during the installation with the configure script
> >>>>>> UNI_POST_HOME: path to your UPPV2.1 build
> >>>>>> POSTEXEC: path to your UPPV2.1 executables”
> >>>>>>
> >>>>>> As for the winds, my WRF output does supply 10 meter winds,
which I
> >>> would
> >>>>>> assume P_Interp would just put at the level (0,*,*), so in
the case
> >>>>>> shouldn't I be able to verify winds as well?
> >>>>>>
> >>>>>> Anyways I tried your fix and while it does run I'm not
actually
> getting
> >>>>> any
> >>>>>> values. I'm fairly certain its because I specified the Level
for the
> >>> obs
> >>>>>> at, "P1000". I'm not sure how to specify the level as the
"surface"
> or
> >>> 10
> >>>>>> meters though.
> >>>>>>
> >>>>>> DEBUG 2:
> >>>>>> ------------------------------------------------------------
> >>>>>> --------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: Reading data for T2(0,*,*).
> >>>>>> DEBUG 2: For T2(0,*,*) found 1 forecast levels and 0
climatology
> >>> levels.
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2:
> >>>>>> ------------------------------------------------------------
> >>>>>> --------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: Searching 41979 observations from 6956 messages.
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2:
> >>>>>> ------------------------------------------------------------
> >>>>>> --------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPUPA, over region FULL, for interpolation method
NEAREST(1),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPUPA, over region FULL, for interpolation method MEDIAN(9),
using
> 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPUPA, over region FULL, for interpolation method
DW_MEAN(9),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPSFC, over region FULL, for interpolation method
NEAREST(1),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPSFC, over region FULL, for interpolation method MEDIAN(9),
using
> 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> ADPSFC, over region FULL, for interpolation method
DW_MEAN(9),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> MSONET, over region FULL, for interpolation method
NEAREST(1),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> MSONET, over region FULL, for interpolation method MEDIAN(9),
using
> 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> MSONET, over region FULL, for interpolation method
DW_MEAN(9),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> SRFSHP, over region FULL, for interpolation method
NEAREST(1),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> SRFSHP, over region FULL, for interpolation method MEDIAN(9),
using
> 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> SRFSHP, over region FULL, for interpolation method
DW_MEAN(9),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> VADWND, over region FULL, for interpolation method
NEAREST(1),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> VADWND, over region FULL, for interpolation method MEDIAN(9),
using
> 0
> >>>>>> pairs.
> >>>>>> DEBUG 2: Processing T2(0,*,*) versus TMP/P1000, for
observation type
> >>>>>> VADWND, over region FULL, for interpolation method
DW_MEAN(9),
> using 0
> >>>>>> pairs.
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2:
> >>>>>> ------------------------------------------------------------
> >>>>>> --------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 1: Output file:
> >>>>>> ../work/point_stat/point_stat_060000L_20160812_120000V.stat
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_fho.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_ctc.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_cts.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_cnt.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sl1l2.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_sal1l2.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_vl1l2.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_val1l2.txt
> >>>>>> DEBUG 1: Output file:
> >>>>>>
../work/point_stat/point_stat_060000L_20160812_120000V_mpr.txt
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Matthew G. Dawson, Capt, USAF
> >>>>>> AFIT Student, Civilian Institution Program
> >>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> <mailto:
> >>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>>>>
> >>>>>> On Feb 8, 2017, at 5:58 PM, John Halley Gotway via RT <
> >>> met_help at ucar.edu <mailto:met_help at ucar.edu>
> >>>>> <mailto:met_help at ucar.edu <mailto:met_help at ucar.edu>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Matthew,
> >>>>>>
> >>>>>> I see that you have some questions about running the Point-
Stat
> tool.
> >>>>>>
> >>>>>> Regarding post-processing, I'd suggest switching from the
pinterp
> >>> utility
> >>>>>> to using the Unified Post-Processor (UPP). It writes output
in GRIB
> >>>>> which
> >>>>>> MET can easily handle. Why pinterp output could work fine
for
> precip,
> >>>>>> temperature, and dewpoint, MET won't be able to process the
winds
> since
> >>>>>> they're defined on the staggered dimension. I realize that
running
> >>> UPP,
> >>>>>> yet another tool to compile and script up, can be a hassle.
But I
> >>> think
> >>>>>> it'll be less work in the long run.
> >>>>>>
> >>>>>> But as for your specific error from Point-Stat, I suspect
that'll be
> >>> easy
> >>>>>> to fix. In your Point-Stat config file, try using:
> >>>>>> name = "T2";
> >>>>>> level = [ "(0,*,*)" ];
> >>>>>>
> >>>>>> I often like plotting the data first:
> >>>>>> met-5.2/bin/plot_data_plane \
> >>>>>> ../../../P_INTERP/preproc/ndown/linout/lin/day1/wrfout_
> >>>>>> d01_2016-08-12_12:00:00_PLEV
> >>>>>> \
> >>>>>> T2.ps \
> >>>>>> 'name="T2"; level="(0,*,*)";'
> >>>>>>
> >>>>>> Hopefully that'll create a PostScript plot of your data.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> John Halley Gotway
> >>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >>> <mailto:met_help at ucar.edu>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Feb 7, 2017 at 7:27 PM, dawsonmattg at gmail.com
<mailto:
> >>> dawsonmattg at gmail.com> <mailto:
> >>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> via RT <
> >>>>>> met_help at ucar.edu <mailto:met_help at ucar.edu> <mailto:
> met_help at ucar.edu
> >>> <mailto:met_help at ucar.edu>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Tue Feb 07 19:27:38 2017: Request 79384 was acted upon.
> >>>>>> Transaction: Ticket created by dawsonmattg at gmail.com <mailto:
> >>> dawsonmattg at gmail.com> <mailto:
> >>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>>> Queue: met_help
> >>>>>> Subject: Point Stat help
> >>>>>> Owner: Nobody
> >>>>>> Requestors: dawsonmattg at gmail.com
<mailto:dawsonmattg at gmail.com>
> >>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>>> Status: new
> >>>>>> Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=79384 <
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384> <
> >>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384 <
> >>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=79384>> >
> >>>>>>
> >>>>>>
> >>>>>> Hello MET help,
> >>>>>>
> >>>>>> I’m going to go ahead and apologize for all the
information in
> >>>>>> this email, but hopefully it will help you better diagnose
what the
> >>> best
> >>>>>> way for me to move forward is. As part of my research I
generated 12
> >>>>>> different WRF runs over the same week using the same I.C.s
and
> B.C.s,
> >>> and
> >>>>>> am currently in the process of comparing them against real
world
> >>>>>> observations to see which config worked the best. I am
primary
> >>> concerned
> >>>>>> with comparing precip, surface temp/dewpoint, and surface
winds.
> >>>>>>
> >>>>>> The first tool I have tried to use has been the point stat
tool.
> I
> >>>>>> am using your met-5.2_bugfix package and did not find any
errors
> >>>>>> while/after compiling and made sure the test files, like
> >>>>>> test_point_stat.sh, all work. The data I am using is as
follows:
> >>>>>>
> >>>>>>
> >>>>>> Instead of downloading prepbufer files and
converting
> them
> >>>>>> with the PB2NC tool, I just used the UCAR site to do it for
me (
> >>>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su
<
> >>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_su>
> >>>>> bset.php?_da=y <http://rda.ucar.edu/datasets/ <
> >>> http://rda.ucar.edu/datasets/>
> >>>>> ds337.0/index.html#forms/337_subset.php?_da=y>
> >>>>>> <http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> >>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_> <
> >>>>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_ <
> >>> http://rda.ucar.edu/datasets/ds337.0/index.html#forms/337_>>
> >>>>>> subset.php?_da=y>)
> >>>>>> Request Detail:
> >>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>>>>> NCEP Verification Regions : SEC
> >>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND
RH MIXR
> >>> PRMSL
> >>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI
AIRCFT
> QKSWND
> >>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>>>>> Quality Mark Threshold : 9
> >>>>>> File Compression : gz
> >>>>>> Data Output Format : NETCDF
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> To convert my WRF data into a readable format I used
P_Interp. I
> >>>>>> am now realizing this might not be the best way forward, but
seemed
> the
> >>>>>> easiest to set up as I had to offload all my model output to
a
> >>> different
> >>>>>> cluster that I did not configure WRF on. I have been a bit
confused
> as
> >>>>>> P_Interp says it can unstager data to pressure levels, but on
your
> >>>>> website
> >>>>>> it says that P_Interp cannot onstager data (at least for use
with
> MODE
> >>>>> and
> >>>>>> other tools). Either way do you think I should try use a
different
> >>>>>> pre-processing software to unpack my WRF data or will
P_Interp be
> >>>>>> sufficient to compare precip, surface temp/dewpoint and
winds?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> When I run my file PointStat.sh using the attached
> >>>>>> PointStatConfig1 file, I get the following data error
message:
> >>>>>>
> >>>>>> *** Running Point-Stat on prepbuffer files ***
> >>>>>> DEBUG 1: Default Config File: /marge/r0/mdawson/met/met-5.2_
> >>>>>> bugfix/share/met/config/PointStatConfig_default
> >>>>>> DEBUG 1: User Config File: config/PointStatConfig
> >>>>>> GSL_RNG_TYPE=mt19937
> >>>>>> GSL_RNG_SEED=1
> >>>>>> DEBUG 1: Forecast File: ../../../P_INTERP/preproc/
> >>>>>> ndown/linout/lin/day1/wrfout_d01_2016-08-12_12:00:00_PLEV
> >>>>>> DEBUG 1: Observation File: ../data/prepbuffer/12/prepbufr
> >>>>>> .gdas.225564.2016081200.nc
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: ------------------------------
> ------------------------------
> >>>>>> --------------------
> >>>>>> DEBUG 2:
> >>>>>> DEBUG 2: Reading data for T2(*,*,0).
> >>>>>> WARNING:
> >>>>>> WARNING: PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
> >>>>> double
> >>>>>> &) const -> star found in bad slot
> >>>>>> WARNING:
> >>>>>> ERROR :
> >>>>>> ERROR : PinterpFile::valid_time(int) const -> range check
error
> >>>>>> ERROR :
> >>>>>>
> >>>>>>
> >>>>>> Looking at the ncdump P_Interp File, T2 (2 meter temperature
shows):
> >>>>>> float T2(Time, south_north, west_east) ;
> >>>>>> T2:FieldType = 104 ;
> >>>>>> T2:MemoryOrder = "XY " ;
> >>>>>> T2:description = "TEMP at 2 M" ;
> >>>>>> T2:units = "K" ;
> >>>>>> T2:stagger = "" ;
> >>>>>> T2:coordinates = "XLONG XLAT XTIME" ;
> >>>>>> T2:missing_value = 1.e+36f ;
> >>>>>>
> >>>>>> I am not sure if the issue is that P_Interp is not properly
> extracting
> >>>>>> this information, or If I just need to change my
PointStatConfig1
> file.
> >>>>>>
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>>
> >>>>>> Matthew G. Dawson, Capt, USAF
> >>>>>> AFIT Student, Civilian Institution Program
> >>>>>> Email: Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
> <mailto:
> >>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>> <mailto:
> >>>>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com> <mailto:
> >>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>
> >>>>>> <Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>
<mailto:
> >>> Dawsonmattg at gmail.com <mailto:Dawsonmattg at gmail.com>>>>
> >>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>>>>
> >>>>>> On Feb 7, 2017, at 11:49 AM, Thomas Cram <tcram at ucar.edu
<mailto:
> >>> tcram at ucar.edu> <mailto:
> >>>>> tcram at ucar.edu <mailto:tcram at ucar.edu>> <mailto:
> >>>>>>
> >>>>>> tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
> <mailto:
> >>> tcram at ucar.edu>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Hi Matthew,
> >>>>>>
> >>>>>> I recommend contacting MET support (cc'd here). It's
possible you
> >>>>>>
> >>>>>> should be using the PrepBUFR data instead of the NetCDF data
in MET,
> >>> but
> >>>>>> having no experience using MET, I am merely speculating on
this.
> MET
> >>>>>> support should be able to help you out.
> >>>>>>
> >>>>>>
> >>>>>> Good luck,
> >>>>>> - Tom
> >>>>>>
> >>>>>> On Tue, Feb 7, 2017 at 9:27 AM, Dawson, Matthew <
> dawsonmattg at gmail.com
> >>> <mailto:dawsonmattg at gmail.com>
> >>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>
> >>>>>>
> >>>>>> <mailto:dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>
> <mailto:
> >>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>> <
> >>>>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com> <mailto:
> >>> dawsonmattg at gmail.com <mailto:dawsonmattg at gmail.com>>>>> wrote:
> >>>>>>
> >>>>>> Hey Thomas
> >>>>>>
> >>>>>> I was able to get the data download with no issues, however I
have
> been
> >>>>>>
> >>>>>> having issues with actually using that data in MET. I am
trying to
> >>>>> compare
> >>>>>> it to some WRF output (used P-Interp to convert into a MET
readable
> >>>>>> format), but the PointStatConfig file keeps having issues
(I’m not
> >>> sure I
> >>>>>> filled it out correctly). Anyways I was wondering if you, or
anyone
> >>>>>> happened to know of an online resource, or even someone who
had a
> >>>>>> configuration set up for comparing data against WRF data so I
can
> >>> compare
> >>>>>> what I have against there config files and hopefully figure
out
> where I
> >>>>> am
> >>>>>> going wrong. I’ve been looking through the MET user guide but
> haven’t
> >>>>> found
> >>>>>> a solution yet. Thanks!
> >>>>>>
> >>>>>>
> >>>>>> Matthew G. Dawson, Capt, USAF
> >>>>>> AFIT Student, Civilian Institution Program
> >>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> >>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>> <mailto:
> >>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>
<mailto:mgd08 at my.fsu.edu
> >>> <mailto:mgd08 at my.fsu.edu>> <mgd08 at my.fsu.edu
<mailto:mgd08 at my.fsu.edu>
> >>> <mailto:
> >>>>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>>>
> >>>>>> Cell: (904)-333-5427 <(904)%20333-5427> <tel:%28904%29-333-
5427
> >>> <tel:%28904%29-333-5427>
> >>>>> <tel:%28904%29-333-5427 <tel:%28904%29-333-5427>>
> >>>>>> <%28904%29-333-5427>>
> >>>>>>
> >>>>>> On Jan 24, 2017, at 1:26 PM, tcram at ucar.edu
<mailto:tcram at ucar.edu>
> >>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
> >>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:
> tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu>>
> >>>>>> <tcram at ucar.edu <mailto:tcram at ucar.edu>
<mailto:tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu>>>>
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Your subset request for NCEP ADP Global Upper Air and Surface
> Weather
> >>>>>>
> >>>>>> Observations has completed.
> >>>>>>
> >>>>>> Please login to the NCAR RDA server at http://rda.ucar.edu <
> >>> http://rda.ucar.edu/> <
> >>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>> <
> >>>>>>
> >>>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
> >>> http://rda.ucar.edu/>>>, then download your files
> >>>>> from the
> >>>>>>
> >>>>>> following URL:
> >>>>>>
> >>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> >>> http://rda.ucar.edu/#dsrqst/DAWSON225564/> <
> http://rda.ucar.edu/#dsrqst/D
> >>> <http://rda.ucar.edu/#dsrqst/D>
> >>>>> AWSON225564/> <
> >>>>>>
> >>>>>> http://rda.ucar.edu/#dsrqst/DAWSON225564/ <
> >>> http://rda.ucar.edu/#dsrqst/DAWSON225564/> <
> http://rda.ucar.edu/#dsrqst/D
> >>> <http://rda.ucar.edu/#dsrqst/D>
> >>>>> AWSON225564/>>
> >>>>>>
> >>>>>>
> >>>>>> Request ID: DAWSON225564
> >>>>>>
> >>>>>> Request Detail:
> >>>>>> Date Limits : 2016-08-12 00:00 2016-08-20 06:00
> >>>>>> NCEP Verification Regions : SEC
> >>>>>> Parameters : SPFH TMP HGT UGRD VGRD DPT WIND
RH MIXR
> >>>>>>
> >>>>>> PRMSL
> >>>>>>
> >>>>>> PREPBUFR Message Types : ADPUPA SFCSHP AIRCAR SPSSMI
AIRCFT
> QKSWND
> >>>>>>
> >>>>>> SATWND RASSDA PROFLR WDSATR VADWND ASCATW ADPSFC
> >>>>>>
> >>>>>> Quality Mark Threshold : 9
> >>>>>> File Compression : gz
> >>>>>> Data Output Format : NETCDF
> >>>>>>
> >>>>>>
> >>>>>> The "rda-request-manager" command line tool provides an
additional
> >>>>>>
> >>>>>> option for users to download
> >>>>>>
> >>>>>> request output files on unix based systems. The
> "rda-request-manager"
> >>>>>>
> >>>>>> tool can be accessed at:
> >>>>>>
> >>>>>>
> >>>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> >>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>> <
> >>>>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps> <
> >>> http://rda.ucar.edu/#apps <http://rda.ucar.edu/#apps>>>
> >>>>>>
> >>>>>> The data provided in your data request are a subset of the
NCAR RDA
> >>>>>>
> >>>>>> dataset ds337.0 --
> >>>>>>
> >>>>>> 'NCEP ADP Global Upper Air and Surface Weather Observations
> (PREPBUFR
> >>>>>>
> >>>>>> format), May 1997 - Continuing'. Please see
> >>>>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>
<
> >>> http://rda.ucar.edu/datasets/ <http://rda.ucar.edu/datasets/>>
> >>>>>> ds337.0/ <http://rda.ucar.edu/datasets/ds337.0/ <
> >>> http://rda.ucar.edu/datasets/ds337.0/> <
> >>>>> http://rda.ucar.edu/datasets/ds337.0/
<http://rda.ucar.edu/datasets/
> >>> ds337.0/>>> for more information.
> >>>>>>
> >>>>>>
> >>>>>> Your data will remain on our system for 5 days. If this is
not
> >>>>>>
> >>>>>> sufficient time for you to retrieve
> >>>>>>
> >>>>>> your data, please let me know as soon as possible, so that I
can
> >>>>>>
> >>>>>> prevent the data files from being
> >>>>>>
> >>>>>> purged too soon.
> >>>>>>
> >>>>>> If you have any questions related to this data request,
please let
> me
> >>>>>>
> >>>>>> know by replying to this
> >>>>>>
> >>>>>> email.
> >>>>>>
> >>>>>> Sincerely,
> >>>>>>
> >>>>>> Thomas Cram
> >>>>>> NCAR/CISL/Data Support Section
> >>>>>> Phone: (303)-497-1217 <(303)%20497-1217> <tel:%28303%29-497-
1217
> >>> <tel:%28303%29-497-1217>
> >>>>> <tel:%28303%29-497-1217 <tel:%28303%29-497-1217>>
> >>>>>> <%28303%29-497-1217>>
> >>>>>> Email: tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:
> tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >
> >>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
<tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >>>>
> >>>>>> Web: http://rda.ucar.edu <http://rda.ucar.edu/> <
> http://rda.ucar.edu/
> >>> <http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
> >>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Thomas Cram
> >>>>>> NCAR / CISL / DSS
> >>>>>> tel: +1-303-497-1217 <(303)%20497-1217>
> >>>>>> e-mail: tcram at ucar.edu <mailto:tcram at ucar.edu> <mailto:
> tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu>> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >
> >>>>> <mailto:tcram at ucar.edu <mailto:tcram at ucar.edu>>
<tcram at ucar.edu
> >>> <mailto:tcram at ucar.edu> <mailto:tcram at ucar.edu
<mailto:tcram at ucar.edu
> >>>>
> >>>>>> web: rda.ucar.edu <http://rda.ucar.edu/>
<http://rda.ucar.edu/ <
> >>> http://rda.ucar.edu/>> <http://rda.ucar.edu/
<http://rda.ucar.edu/> <
> >>>>> http://rda.ucar.edu/ <http://rda.ucar.edu/>>>
> >>>>>>
> >>>>>>
> >>>>>> Matthew G. Dawson, Capt, USAF
> >>>>>> AFIT Student, Civilian Institution Program
> >>>>>> Email: mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu> <mailto:
> >>> mgd08 at my.fsu.edu <mailto:mgd08 at my.fsu.edu>>
> >>>>>> Cell: (904)-333-5427 <(904)%20333-5427>
> >>>
> >>>
> >>>
> >>
> >
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list