[Met_help] [rt.rap.ucar.edu #96458] History for Tropical Cyclone verification: TCPairs and CyclonePlotter
George McCabe via RT
met_help at ucar.edu
Thu Aug 27 09:58:15 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Good afternoon,
I found it relatively straightforward to set-up some scripts to process
forecast output along with obs by using this resource:
https://dtcenter.github.io/METplus/generated/model_applications/tc_and_extra_tc/Plotter_fcstGFS_obsGFS_ExtraTC.html#sphx-glr-generated-model-applications-tc-and-extra-tc-plotter-fcstgfs-obsgfs-extratc-py.
I have been running the global model which generates track data for the
post processing step following this naming convention:
atcfunix.gfs.YYYYMMDDHH. The best track data is stored here on WCOSS:
/gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/.
I have a python script that determines which file to use based on basin
information, storm name, and date. That is piped into the
TC_PAIRS_BDECK_TEMPLATE while the forecast file above is piped into the
TC_PAIRS_ADECK_TEMPLATE this way: atcfunix.gfs.{date?fmt=%Y%m%d%H}.
Inside my main script
*(/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/scripts/run_metplus_TCPlotter.sh*,
I have three configure files that being processed like so:*
${MET_PLUS}/ush/master_metplus.py -c
${MET_PLUS_CONF}/Plotter_fcstGFS_obsGFS_ExtraTC.conf -c
${MET_PLUS_TMP}/shared.conf_TC -c ${MET_PLUS_CONF}/system_TC.conf*
The system_TC.conf is of little concern because it is mostly unchanged
except for the OUTPUT_BASE, which is changed specifically to where I plan
on storing the TC output. The shared_TC.conf, on the other hand, is used
to replace the content inside my Plotter_fcstGFS_obsGFS_ExtraTC.conf file.
In here I define
the ADECK and BDECK input directories based on the where the template files
above are being stored. Since I have several runs encompassing the
tropical cyclone event - 20190924 through 20190929 - I have specified my
INIT_BEG as 20190924 and my INIT_END as 20190929. I have also set my
INIT_INCREMENT to 86400 since I'm only processing the 00z cycle for now. I
have a couple of lines of code before the configure file that joins these
dates in a comma separated list such that the CYCLONE_PLOTTER_INIT_DATE is
"20190924,20190925,...,20190929". I'm not sure if that is allowed though.
When running the script the log that is generated produces 0 errors.
However, I find *two issues*: *1) there is only one file being carried
over to generate results; that is the 20190924 date - there should be 6*,
and *2) The files that are created are empty and thus the plot that is
generated is simply a map with no data overlaid.*
In attempting to debug further, I found something that looks important
shown here:
DEBUG 3: Rejected for init mask = 0
DEBUG 3: Rejected for valid mask = 0
*DEBUG 2: Matching 0 ADECK tracks to 0 BDECK tracks.*
DEBUG 1: Watch/Warning file:
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/share/met/tc_data/wwpts_us.txt
DEBUG 5: TrackPairInfoArray: NPairs = 0, NAlloc = 0, Pairs:
DEBUG 5:
DEBUG 1: Output file:
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
08/26 18:35:12.422 metplus.TCPairs (command_runner.py:191) DEBUG: Finished
running
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/bin/tc_pairs
in 0:00:00.607349
08/26 18:35:12.422 metplus.CyclonePlotter (cyclone_plotter_wrapper.py:77)
DEBUG: Begin retrieving data...
08/26 18:35:12.422 metplus.CyclonePlotter (cyclone_plotter_wrapper.py:83)
DEBUG: Generate plot for all files in the
directory/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs
08/26 18:35:12.423 metplus.CyclonePlotter (cyclone_plotter_wrapper.py:98)
DEBUG: Parsing file
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
08/26 18:35:19.778 metplus (config_launcher.py:520) DEBUG: Setting [config]
SCRUB_STAGING_DIR to default value: False.
08/26 18:35:19.779 metplus INFO:
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/metplus_final.conf:
write metplus.conf here
08/26 18:35:19.783 metplus (met_util.py:213) DEBUG: METplus took
0:00:08.783240 to run.
08/26 18:35:19.783 metplus INFO: METplus has successfully finished running.
Specifically the line that says matching 0 ADECK tracks to 0 BDECK tracks
lends me to believe that this is the reason why nothing is being added to
my TC_PAIRS_OUTPUT_TEMPLATE file, and therefore no plots generated on a
map.
What's interesting is the file that is extracted for BDECK is for hurricane
Lorenzo and includes all the dates coinciding with the ADECK file - a case
that is run coinciding with Lorenzo. I've checked this.
One possible issue is the formatting of these files. I looked in the test
case that comes with the cloned met stuff. In there the header/field info
looks something like this:
*/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/source_data/met_test/new/track_data/201412/amlq2014123118.gfso.0104*
ML, 0104, 2014121318_F000_478N_1780W_FOF, 2014121318, 03, GFSO, 000, 478N,
1780W, 38, 986, XX, 34, NEQ, 0283, 0640, 0645, 0000, 990, 133, -99,
69, 227, -99, -9999, -9999, 208, 315, 135, 156, 0063
This differs from the structure of both the ADECK and BDECK input files:
*BDECK:
/gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/bal132019.dat *
AL, 13, 2019092218, , BEST, 0, 109N, 188W, 25, 1008, LO, 0, ,
0, 0, 0, 0, 1012, 100, 90, 40, 0, L, 0, , 0, 0,
INVEST, S, 0, , 0, 0, 0, 0, genesis-num, 027,
*ADECK:
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/archive/prna20/atcfunix.gfs.2019092400*
AL, 0912, 03, PRNA, 000, 157N, 655W, 27, 1008, XX, 34, NEQ, 0000, 0000,
0000, 0000, -9999, -9999, 85
My suspicion is that these formats are not compatible. There are major
differences between these formats in my opinion. The ADECK was generated
automatically when making a run while BDECK is done by someone else. Those
files are stored whenever a storm is identified.
I think what I'll need to do next is start by running TCRMW to produce the
ADECK files formatted by metplus. I have the grib files for that. The
question next, though, is the BDECK files okay for processing?
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Tropical Cyclone verification: TCPairs and CyclonePlotter
From: George McCabe
Time: Wed Aug 26 16:50:53 2020
Hi Edward,
The BDECK data is compatible to be processed. The use case you used as
an
example uses extra tropical cyclone data from SBU that is reformatted
by
TCPairs wrapper before processing. You will see your config file has
the
following:
## tc-pairs filtering optionsTC_PAIRS_REFORMAT_DECK =
yesTC_PAIRS_REFORMAT_TYPE = SBU
Changing TC_PAIRS_REFORMAT_DECK to 'no' or 'false' will skip the
reformatting step. There is another use case in the repo that uses
data
that looks like yours (at least as far as I can tell).
https://dtcenter.github.io/METplus/generated/met_tool_wrapper/TCPairs/TCPairs_tropical.html#metplus-
configuration
This use case uses BDECK data in met_test/new/hwrf/bdeck. Here is part
of
the file called bal062018.dat:
AL, 06, 2018082906, , BEST, 0, 129N, 109W, 10, 1010, DB, 0,
,
0, 0, 0, 0, 0, 0, 0, 0, 0, , 0, , 0,
0,
GENESIS019, , 0, , 0, 0, 0, 0, genesis-num, 019,
Let me know if changing that setting doesn't work and I can take a
closer
look.
Thanks,
George
On Wed, Aug 26, 2020 at 1:17 PM Edward Strobach - NOAA Affiliate via
RT <
met_help at ucar.edu> wrote:
>
> Wed Aug 26 13:13:28 2020: Request 96458 was acted upon.
> Transaction: Ticket created by edward.strobach at noaa.gov
> Queue: met_help
> Subject: Tropical Cyclone verification: TCPairs and
CyclonePlotter
> Owner: Nobody
> Requestors: edward.strobach at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96458 >
>
>
> Good afternoon,
>
> I found it relatively straightforward to set-up some scripts to
process
> forecast output along with obs by using this resource:
>
>
https://dtcenter.github.io/METplus/generated/model_applications/tc_and_extra_tc/Plotter_fcstGFS_obsGFS_ExtraTC.html#sphx-
glr-generated-model-applications-tc-and-extra-tc-plotter-fcstgfs-
obsgfs-extratc-py
> .
> I have been running the global model which generates track data for
the
> post processing step following this naming convention:
> atcfunix.gfs.YYYYMMDDHH. The best track data is stored here on
WCOSS:
> /gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/.
>
> I have a python script that determines which file to use based on
basin
> information, storm name, and date. That is piped into the
> TC_PAIRS_BDECK_TEMPLATE while the forecast file above is piped into
the
> TC_PAIRS_ADECK_TEMPLATE this way: atcfunix.gfs.{date?fmt=%Y%m%d%H}.
>
> Inside my main script
>
>
*(/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/scripts/run_metplus_TCPlotter.sh*,
> I have three configure files that being processed like so:*
> ${MET_PLUS}/ush/master_metplus.py -c
> ${MET_PLUS_CONF}/Plotter_fcstGFS_obsGFS_ExtraTC.conf -c
> ${MET_PLUS_TMP}/shared.conf_TC -c ${MET_PLUS_CONF}/system_TC.conf*
>
> The system_TC.conf is of little concern because it is mostly
unchanged
> except for the OUTPUT_BASE, which is changed specifically to where I
plan
> on storing the TC output. The shared_TC.conf, on the other hand, is
used
> to replace the content inside my Plotter_fcstGFS_obsGFS_ExtraTC.conf
file.
> In here I define
> the ADECK and BDECK input directories based on the where the
template files
> above are being stored. Since I have several runs encompassing the
> tropical cyclone event - 20190924 through 20190929 - I have
specified my
> INIT_BEG as 20190924 and my INIT_END as 20190929. I have also set
my
> INIT_INCREMENT to 86400 since I'm only processing the 00z cycle for
now. I
> have a couple of lines of code before the configure file that joins
these
> dates in a comma separated list such that the
CYCLONE_PLOTTER_INIT_DATE is
> "20190924,20190925,...,20190929". I'm not sure if that is allowed
though.
>
> When running the script the log that is generated produces 0 errors.
> However, I find *two issues*: *1) there is only one file being
carried
> over to generate results; that is the 20190924 date - there should
be 6*,
> and *2) The files that are created are empty and thus the plot that
is
> generated is simply a map with no data overlaid.*
>
> In attempting to debug further, I found something that looks
important
> shown here:
>
> DEBUG 3: Rejected for init mask = 0
> DEBUG 3: Rejected for valid mask = 0
> *DEBUG 2: Matching 0 ADECK tracks to 0 BDECK tracks.*
> DEBUG 1: Watch/Warning file:
>
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/share/met/tc_data/wwpts_us.txt
> DEBUG 5: TrackPairInfoArray: NPairs = 0, NAlloc = 0, Pairs:
> DEBUG 5:
> DEBUG 1: Output file:
>
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
> 08/26 18:35:12.422 metplus.TCPairs (command_runner.py:191) DEBUG:
Finished
> running
>
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/bin/tc_pairs
> in 0:00:00.607349
> 08/26 18:35:12.422 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:77)
> DEBUG: Begin retrieving data...
> 08/26 18:35:12.422 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:83)
> DEBUG: Generate plot for all files in the
>
>
directory/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs
> 08/26 18:35:12.423 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:98)
> DEBUG: Parsing file
>
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
> 08/26 18:35:19.778 metplus (config_launcher.py:520) DEBUG: Setting
[config]
> SCRUB_STAGING_DIR to default value: False.
> 08/26 18:35:19.779 metplus INFO:
>
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/metplus_final.conf:
> write metplus.conf here
> 08/26 18:35:19.783 metplus (met_util.py:213) DEBUG: METplus took
> 0:00:08.783240 to run.
> 08/26 18:35:19.783 metplus INFO: METplus has successfully finished
running.
>
> Specifically the line that says matching 0 ADECK tracks to 0 BDECK
tracks
> lends me to believe that this is the reason why nothing is being
added to
> my TC_PAIRS_OUTPUT_TEMPLATE file, and therefore no plots generated
on a
> map.
>
> What's interesting is the file that is extracted for BDECK is for
hurricane
> Lorenzo and includes all the dates coinciding with the ADECK file -
a case
> that is run coinciding with Lorenzo. I've checked this.
>
> One possible issue is the formatting of these files. I looked in
the test
> case that comes with the cloned met stuff. In there the
header/field info
> looks something like this:
>
>
>
*/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/source_data/met_test/new/track_data/201412/amlq2014123118.gfso.0104*
>
> ML, 0104, 2014121318_F000_478N_1780W_FOF, 2014121318, 03, GFSO, 000,
478N,
> 1780W, 38, 986, XX, 34, NEQ, 0283, 0640, 0645, 0000, 990, 133,
-99,
> 69, 227, -99, -9999, -9999, 208, 315, 135, 156, 0063
>
> This differs from the structure of both the ADECK and BDECK input
files:
>
> *BDECK:
>
/gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/bal132019.dat
*
>
> AL, 13, 2019092218, , BEST, 0, 109N, 188W, 25, 1008, LO, 0,
,
> 0, 0, 0, 0, 1012, 100, 90, 40, 0, L, 0, , 0,
0,
> INVEST, S, 0, , 0, 0, 0, 0, genesis-num, 027,
>
> *ADECK:
>
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/archive/prna20/atcfunix.gfs.2019092400*
>
> AL, 0912, 03, PRNA, 000, 157N, 655W, 27, 1008, XX, 34, NEQ, 0000,
0000,
> 0000, 0000, -9999, -9999, 85
>
> My suspicion is that these formats are not compatible. There are
major
> differences between these formats in my opinion. The ADECK was
generated
> automatically when making a run while BDECK is done by someone else.
Those
> files are stored whenever a storm is identified.
>
> I think what I'll need to do next is start by running TCRMW to
produce the
> ADECK files formatted by metplus. I have the grib files for that.
The
> question next, though, is the BDECK files okay for processing?
>
>
>
> --
> Edward Strobach
> EMC/NCEP/NWS/
> IMSG Contractor
> Cubicle#: 2029
> 301-683-3717
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Tropical Cyclone verification: TCPairs and CyclonePlotter
From: Edward Strobach - NOAA Affiliate
Time: Thu Aug 27 09:52:48 2020
Hi George, I figured the BDECK must be compatible, so no worries
there.
Thanks for the link and the heads up about reformatting. I will use
the
example to modify what I currently have to see the outcome. Thanks
again.
On Wed, Aug 26, 2020 at 6:57 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Edward,
>
> The BDECK data is compatible to be processed. The use case you used
as an
> example uses extra tropical cyclone data from SBU that is
reformatted by
> TCPairs wrapper before processing. You will see your config file has
the
> following:
>
> ## tc-pairs filtering optionsTC_PAIRS_REFORMAT_DECK =
> yesTC_PAIRS_REFORMAT_TYPE = SBU
>
> Changing TC_PAIRS_REFORMAT_DECK to 'no' or 'false' will skip the
> reformatting step. There is another use case in the repo that uses
data
> that looks like yours (at least as far as I can tell).
>
>
>
https://dtcenter.github.io/METplus/generated/met_tool_wrapper/TCPairs/TCPairs_tropical.html#metplus-
configuration
>
> This use case uses BDECK data in met_test/new/hwrf/bdeck. Here is
part of
> the file called bal062018.dat:
>
> AL, 06, 2018082906, , BEST, 0, 129N, 109W, 10, 1010, DB, 0,
,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, , 0, , 0,
0,
> GENESIS019, , 0, , 0, 0, 0, 0, genesis-num, 019,
>
>
> Let me know if changing that setting doesn't work and I can take a
closer
> look.
>
> Thanks,
> George
>
> On Wed, Aug 26, 2020 at 1:17 PM Edward Strobach - NOAA Affiliate via
RT <
> met_help at ucar.edu> wrote:
>
> >
> > Wed Aug 26 13:13:28 2020: Request 96458 was acted upon.
> > Transaction: Ticket created by edward.strobach at noaa.gov
> > Queue: met_help
> > Subject: Tropical Cyclone verification: TCPairs and
CyclonePlotter
> > Owner: Nobody
> > Requestors: edward.strobach at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96458 >
> >
> >
> > Good afternoon,
> >
> > I found it relatively straightforward to set-up some scripts to
process
> > forecast output along with obs by using this resource:
> >
> >
>
https://dtcenter.github.io/METplus/generated/model_applications/tc_and_extra_tc/Plotter_fcstGFS_obsGFS_ExtraTC.html#sphx-
glr-generated-model-applications-tc-and-extra-tc-plotter-fcstgfs-
obsgfs-extratc-py
> > .
> > I have been running the global model which generates track data
for the
> > post processing step following this naming convention:
> > atcfunix.gfs.YYYYMMDDHH. The best track data is stored here on
WCOSS:
> > /gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/.
> >
> > I have a python script that determines which file to use based on
basin
> > information, storm name, and date. That is piped into the
> > TC_PAIRS_BDECK_TEMPLATE while the forecast file above is piped
into the
> > TC_PAIRS_ADECK_TEMPLATE this way:
atcfunix.gfs.{date?fmt=%Y%m%d%H}.
> >
> > Inside my main script
> >
> >
>
*(/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/scripts/run_metplus_TCPlotter.sh*,
> > I have three configure files that being processed like so:*
> > ${MET_PLUS}/ush/master_metplus.py -c
> > ${MET_PLUS_CONF}/Plotter_fcstGFS_obsGFS_ExtraTC.conf -c
> > ${MET_PLUS_TMP}/shared.conf_TC -c ${MET_PLUS_CONF}/system_TC.conf*
> >
> > The system_TC.conf is of little concern because it is mostly
unchanged
> > except for the OUTPUT_BASE, which is changed specifically to where
I plan
> > on storing the TC output. The shared_TC.conf, on the other hand,
is used
> > to replace the content inside my
Plotter_fcstGFS_obsGFS_ExtraTC.conf
> file.
> > In here I define
> > the ADECK and BDECK input directories based on the where the
template
> files
> > above are being stored. Since I have several runs encompassing
the
> > tropical cyclone event - 20190924 through 20190929 - I have
specified my
> > INIT_BEG as 20190924 and my INIT_END as 20190929. I have also set
my
> > INIT_INCREMENT to 86400 since I'm only processing the 00z cycle
for
> now. I
> > have a couple of lines of code before the configure file that
joins these
> > dates in a comma separated list such that the
CYCLONE_PLOTTER_INIT_DATE
> is
> > "20190924,20190925,...,20190929". I'm not sure if that is allowed
> though.
> >
> > When running the script the log that is generated produces 0
errors.
> > However, I find *two issues*: *1) there is only one file being
carried
> > over to generate results; that is the 20190924 date - there should
be 6*,
> > and *2) The files that are created are empty and thus the plot
that is
> > generated is simply a map with no data overlaid.*
> >
> > In attempting to debug further, I found something that looks
important
> > shown here:
> >
> > DEBUG 3: Rejected for init mask = 0
> > DEBUG 3: Rejected for valid mask = 0
> > *DEBUG 2: Matching 0 ADECK tracks to 0 BDECK tracks.*
> > DEBUG 1: Watch/Warning file:
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/share/met/tc_data/wwpts_us.txt
> > DEBUG 5: TrackPairInfoArray: NPairs = 0, NAlloc = 0, Pairs:
> > DEBUG 5:
> > DEBUG 1: Output file:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
> > 08/26 18:35:12.422 metplus.TCPairs (command_runner.py:191) DEBUG:
> Finished
> > running
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.1_beta2/bin/tc_pairs
> > in 0:00:00.607349
> > 08/26 18:35:12.422 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:77)
> > DEBUG: Begin retrieving data...
> > 08/26 18:35:12.422 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:83)
> > DEBUG: Generate plot for all files in the
> >
> >
>
directory/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs
> > 08/26 18:35:12.423 metplus.CyclonePlotter
(cyclone_plotter_wrapper.py:98)
> > DEBUG: Parsing file
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/tc_pairs/201909/AL_q2019092400.gfs.PRNA20.tcst
> > 08/26 18:35:19.778 metplus (config_launcher.py:520) DEBUG: Setting
> [config]
> > SCRUB_STAGING_DIR to default value: False.
> > 08/26 18:35:19.779 metplus INFO:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/metplus_TC/TCPlotter/metplus_final.conf:
> > write metplus.conf here
> > 08/26 18:35:19.783 metplus (met_util.py:213) DEBUG: METplus took
> > 0:00:08.783240 to run.
> > 08/26 18:35:19.783 metplus INFO: METplus has successfully finished
> running.
> >
> > Specifically the line that says matching 0 ADECK tracks to 0 BDECK
tracks
> > lends me to believe that this is the reason why nothing is being
added to
> > my TC_PAIRS_OUTPUT_TEMPLATE file, and therefore no plots generated
on a
> > map.
> >
> > What's interesting is the file that is extracted for BDECK is for
> hurricane
> > Lorenzo and includes all the dates coinciding with the ADECK file
- a
> case
> > that is run coinciding with Lorenzo. I've checked this.
> >
> > One possible issue is the formatting of these files. I looked in
the
> test
> > case that comes with the cloned met stuff. In there the
header/field
> info
> > looks something like this:
> >
> >
> >
>
*/gpfs/dell2/emc/modeling/save/Edward.Strobach/MetPlus/METplus/source_data/met_test/new/track_data/201412/amlq2014123118.gfso.0104*
> >
> > ML, 0104, 2014121318_F000_478N_1780W_FOF, 2014121318, 03, GFSO,
000,
> 478N,
> > 1780W, 38, 986, XX, 34, NEQ, 0283, 0640, 0645, 0000, 990,
133, -99,
> > 69, 227, -99, -9999, -9999, 208, 315, 135, 156, 0063
> >
> > This differs from the structure of both the ADECK and BDECK input
files:
> >
> > *BDECK:
> >
/gpfs/hps3/emc/hwrf/noscrub/emc.hurpara/trak/abdeck/btk/bal132019.dat
*
> >
> > AL, 13, 2019092218, , BEST, 0, 109N, 188W, 25, 1008, LO,
0, ,
> > 0, 0, 0, 0, 1012, 100, 90, 40, 0, L, 0, ,
0, 0,
> > INVEST, S, 0, , 0, 0, 0, 0, genesis-num, 027,
> >
> > *ADECK:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Edward.Strobach/archive/prna20/atcfunix.gfs.2019092400*
> >
> > AL, 0912, 03, PRNA, 000, 157N, 655W, 27, 1008, XX, 34, NEQ,
0000,
> 0000,
> > 0000, 0000, -9999, -9999, 85
> >
> > My suspicion is that these formats are not compatible. There are
major
> > differences between these formats in my opinion. The ADECK was
generated
> > automatically when making a run while BDECK is done by someone
else.
> Those
> > files are stored whenever a storm is identified.
> >
> > I think what I'll need to do next is start by running TCRMW to
produce
> the
> > ADECK files formatted by metplus. I have the grib files for that.
The
> > question next, though, is the BDECK files okay for processing?
> >
> >
> >
> > --
> > Edward Strobach
> > EMC/NCEP/NWS/
> > IMSG Contractor
> > Cubicle#: 2029
> > 301-683-3717
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
--
Edward Strobach
EMC/NCEP/NWS/
IMSG Contractor
Cubicle#: 2029
301-683-3717
------------------------------------------------
More information about the Met_help
mailing list