[Met_help] [rt.rap.ucar.edu #80483] History for METplus-filtering one days' worth of data based on area
Tara Jensen via RT
met_help at ucar.edu
Mon Jun 5 12:15:16 MDT 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi Minna,
I mean I could use the data I currently have.
I want to know if I could run a single case in METplus by editing constants_pdef.py and only consider cyclones within the area 260-320E, 25-65N and get the model's results for cyclone relative. Because I need to compare the model's cyclone relative results with my code cyclone relative results.
Thanks,
Xinxia
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Minna Win
Time: Tue May 16 12:52:50 2017
Hi Xinxia,
To isolate your METplus run to your boundary/area of interest, you can
set the EXTRACT_TILES_FILTER_OPTS=" -out_init_mask " +
os.path.join(MET_BUILD_BASE,"share/met/poly/SBU.poly") in your
constants_pdef.py configuration file. METplus utilizes the MET tool,
TC-Stat to accomplish the masking (just as in the
tc2cyclone_relative.py script).
The SBU.poly file that I provided you for use with the
tc2cyclone_relative.py script can be reused here, since we are using
the same masking region of 260-320E, 25-65N (or -40 to -80 and 25-65,
the convention used by MET). As long as you haven't removed the
SBU.poly file, you should be ready to go.
You can read a more succinct explanation of the -out_init_mask option
in the MET documentation:
http://www.dtcenter.org/met/users/docs/users_guide/MET_Users_Guide_v6.0.pdf
under the chapter for the TC-STAT tool (chapter 20).
Good luck!
Regards,
Minna
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Minna Win
Time: Tue May 16 12:59:21 2017
Hi Xinxia,
I don't remember if I had sent the solution to filtering one days'
worth of track data in the constants_pdef.py file in a separate email.
Just in case I didn't, here is how you do it:
set the INIT_DATE_BEG and INIT_DATE_END to the appropriate dates.
If you were only interested in data for 20141201, you would do the
following:
INIT_DATE_BEG="20141201"
INIT_DATE_END = "20141201"
Regards,
Minna
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Thu May 18 13:05:42 2017
Hi Minna,
The METplus run of FBAR (mean) SLP results look kinda different than
mine using the tracks that are filtered.
I'm afraid that 1. the METplus didn't change the focus region to 25-
65N, 260-320E. 2. The tracks I use with my code are not filtered
correctly.
But I don't know how to debug since I don't know where the original
tracks are.
Thanks,
Xinxia
________________________________
From: Minna Win via RT <met_help-comment at rap.ucar.edu>
Sent: Tuesday, May 16, 2017 2:59:22 PM
Cc: xinxia_song at outlook.com
Subject: [rt.rap.ucar.edu #80483] METplus-filtering one days' worth of
data based on area
Hi Xinxia,
I don't remember if I had sent the solution to filtering one days'
worth of track data in the constants_pdef.py file in a separate email.
Just in case I didn't, here is how you do it:
set the INIT_DATE_BEG and INIT_DATE_END to the appropriate dates.
If you were only interested in data for 20141201, you would do the
following:
INIT_DATE_BEG="20141201"
INIT_DATE_END = "20141201"
Regards,
Minna
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Minna Win
Time: Thu May 18 13:38:13 2017
Hi Xinxia,
What date where you using for your analysis? I'd like to replicate
the
filtering on my host. Can you provide your plot of the SLP FBAR
results?
Thanks,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Thu, May 18, 2017 at 7:05 PM, Xinxia Song via RT <
met_help-comment at rap.ucar.edu> wrote:
>
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
> This is a comment. It is not sent to the Requestor(s):
>
> Hi Minna,
> The METplus run of FBAR (mean) SLP results look kinda different than
mine
> using the tracks that are filtered.
> I'm afraid that 1. the METplus didn't change the focus region to 25-
65N,
> 260-320E. 2. The tracks I use with my code are not filtered
correctly.
> But I don't know how to debug since I don't know where the original
tracks
> are.
> Thanks,
> Xinxia
>
>
> ________________________________
> From: Minna Win via RT <met_help-comment at rap.ucar.edu>
> Sent: Tuesday, May 16, 2017 2:59:22 PM
> Cc: xinxia_song at outlook.com
> Subject: [rt.rap.ucar.edu #80483] METplus-filtering one days' worth
of
> data based on area
>
> Hi Xinxia,
>
> I don't remember if I had sent the solution to filtering one days'
worth
> of track data in the constants_pdef.py file in a separate email.
Just in
> case I didn't, here is how you do it:
>
> set the INIT_DATE_BEG and INIT_DATE_END to the appropriate dates.
>
> If you were only interested in data for 20141201, you would do the
> following:
>
> INIT_DATE_BEG="20141201"
> INIT_DATE_END = "20141201"
>
> Regards,
> Minna
>
>
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Mon May 22 08:23:35 2017
Hi Minna,
I use the constants_pdef.py to shrink the MET region the the one that
Fortran code uses. But seems it doesn't do it correctly. Could you
help to check the constants_pdef.py to see where is the problem?
Thanks,
Xinxia
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Minna Win
Time: Mon May 22 16:45:16 2017
Hi Xinxia,
>From what I've found thus far, it looks like the masking by region is
working as expected (this uses the MET tool TC-Stat). In some cases,
there
is a point (or points) that lie outside the boundary because they
belong to
a storm track which has an init time (with lead hour =0) within the
boundary (this is consistent with the -out_init_mask argument used to
do
the masking). The METplus code does not perform any "surgical"
removal of
these few outliers. We get even more outliers when we perform
regridding
with the MET tool regrid_data_plane. This uses the atrack and btrack
lon,lat values and interpolates points using the nearest neighbor
technique. We are requesting 60 lons and 60 lats total for the
regridded
tiles, so if we have a few outliers, by the time we finish regridding
we
end up with even more points that are outside the boundary.
Is this what you were referring to when you thought the region wasn't
getting masked? I used the values in your constants_pdef.py file and
they
look OK.
Thanks,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <Xinxia_Song at outlook.com>
wrote:
> Hi Minna,
>
> I use the constants_pdef.py to shrink the MET region the the one
that
> Fortran code uses. But seems it doesn't do it correctly. Could you
help to
> check the constants_pdef.py to see where is the problem?
>
> Thanks,
>
> Xinxia
>
>
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Wed May 24 07:41:46 2017
Hi Minna,
I think the MET doesn't exclude the points fall outside the boundary
cause we have more cyclones tracked in MET than in Fortran code. Is
there any possibility we exclude them successfully? Otherwise we need
to modify the track file for Fortran code and Fortran code itself.
Thanks,
Xinxia
________________________________
From: Minna Win via RT <met_help at ucar.edu>
Sent: Monday, May 22, 2017 6:45:16 PM
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Xinxia,
>From what I've found thus far, it looks like the masking by region is
working as expected (this uses the MET tool TC-Stat). In some cases,
there
is a point (or points) that lie outside the boundary because they
belong to
a storm track which has an init time (with lead hour =0) within the
boundary (this is consistent with the -out_init_mask argument used to
do
the masking). The METplus code does not perform any "surgical"
removal of
these few outliers. We get even more outliers when we perform
regridding
with the MET tool regrid_data_plane. This uses the atrack and btrack
lon,lat values and interpolates points using the nearest neighbor
technique. We are requesting 60 lons and 60 lats total for the
regridded
tiles, so if we have a few outliers, by the time we finish regridding
we
end up with even more points that are outside the boundary.
Is this what you were referring to when you thought the region wasn't
getting masked? I used the values in your constants_pdef.py file and
they
look OK.
Thanks,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <Xinxia_Song at outlook.com>
wrote:
> Hi Minna,
>
> I use the constants_pdef.py to shrink the MET region the the one
that
> Fortran code uses. But seems it doesn't do it correctly. Could you
help to
> check the constants_pdef.py to see where is the problem?
>
> Thanks,
>
> Xinxia
>
>
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Wed May 24 10:09:09 2017
Hi Xinxia,
Tara here. Minna is out until next week, as am I, and much of our
met_help
staff. We will look into this further next Wed or Thur.
I have not had time to run through the example you and Minna are
working on
so really don't understand how you have it set-up for debugging. If
you
haven't done so yet, I'd suggest running just 1 extra tropical cyclone
track through your system (assuming this is what you refer to as the
Fortran code) and through MET+. You could do so by deleting all
tracks
except one from the input track files (making sure it's the same
track). I
would suggest using your plotting package to plot both the netcdf
output of
the Fortran code and MET+.
If there's a difference between the fields extracted, then we have a
good
place to start. If there isn't a difference, then add another track
in,
run the two systems, compare etc...
Cheers, Tara
On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Minna,
>
>
> I think the MET doesn't exclude the points fall outside the boundary
cause
> we have more cyclones tracked in MET than in Fortran code. Is there
any
> possibility we exclude them successfully? Otherwise we need to
modify the
> track file for Fortran code and Fortran code itself.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Minna Win via RT <met_help at ucar.edu>
> Sent: Monday, May 22, 2017 6:45:16 PM
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> From what I've found thus far, it looks like the masking by region
is
> working as expected (this uses the MET tool TC-Stat). In some
cases, there
> is a point (or points) that lie outside the boundary because they
belong to
> a storm track which has an init time (with lead hour =0) within the
> boundary (this is consistent with the -out_init_mask argument used
to do
> the masking). The METplus code does not perform any "surgical"
removal of
> these few outliers. We get even more outliers when we perform
regridding
> with the MET tool regrid_data_plane. This uses the atrack and btrack
> lon,lat values and interpolates points using the nearest neighbor
> technique. We are requesting 60 lons and 60 lats total for the
regridded
> tiles, so if we have a few outliers, by the time we finish
regridding we
> end up with even more points that are outside the boundary.
>
> Is this what you were referring to when you thought the region
wasn't
> getting masked? I used the values in your constants_pdef.py file
and they
> look OK.
>
> Thanks,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> wrote:
>
> > Hi Minna,
> >
> > I use the constants_pdef.py to shrink the MET region the the one
that
> > Fortran code uses. But seems it doesn't do it correctly. Could you
help
> to
> > check the constants_pdef.py to see where is the problem?
> >
> > Thanks,
> >
> > Xinxia
> >
> >
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Wed May 24 12:52:10 2017
Hi Tara,
I just a little confused with the track information. First, it has two
folders, one is track_data and another is track_data_atcf. Should I
edit both or just one? Then within the track_data folder, it has amlq*
and bmlq* files. which file should I edit And the end is from 0001 to
0280, what does this mean? And when I open the file, it has many
columns, could you help me to find out the critical columns like
timestep, lat, lon and cyclone id?
Below is the first line of amlq2014123118.gfso.0005:
ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO, 000,
280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000, 1011,
178, -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Wednesday, May 24, 2017 12:09:09 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Xinxia,
Tara here. Minna is out until next week, as am I, and much of our
met_help
staff. We will look into this further next Wed or Thur.
I have not had time to run through the example you and Minna are
working on
so really don't understand how you have it set-up for debugging. If
you
haven't done so yet, I'd suggest running just 1 extra tropical cyclone
track through your system (assuming this is what you refer to as the
Fortran code) and through MET+. You could do so by deleting all
tracks
except one from the input track files (making sure it's the same
track). I
would suggest using your plotting package to plot both the netcdf
output of
the Fortran code and MET+.
If there's a difference between the fields extracted, then we have a
good
place to start. If there isn't a difference, then add another track
in,
run the two systems, compare etc...
Cheers, Tara
On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Minna,
>
>
> I think the MET doesn't exclude the points fall outside the boundary
cause
> we have more cyclones tracked in MET than in Fortran code. Is there
any
> possibility we exclude them successfully? Otherwise we need to
modify the
> track file for Fortran code and Fortran code itself.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Minna Win via RT <met_help at ucar.edu>
> Sent: Monday, May 22, 2017 6:45:16 PM
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> From what I've found thus far, it looks like the masking by region
is
> working as expected (this uses the MET tool TC-Stat). In some
cases, there
> is a point (or points) that lie outside the boundary because they
belong to
> a storm track which has an init time (with lead hour =0) within the
> boundary (this is consistent with the -out_init_mask argument used
to do
> the masking). The METplus code does not perform any "surgical"
removal of
> these few outliers. We get even more outliers when we perform
regridding
> with the MET tool regrid_data_plane. This uses the atrack and btrack
> lon,lat values and interpolates points using the nearest neighbor
> technique. We are requesting 60 lons and 60 lats total for the
regridded
> tiles, so if we have a few outliers, by the time we finish
regridding we
> end up with even more points that are outside the boundary.
>
> Is this what you were referring to when you thought the region
wasn't
> getting masked? I used the values in your constants_pdef.py file
and they
> look OK.
>
> Thanks,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> wrote:
>
> > Hi Minna,
> >
> > I use the constants_pdef.py to shrink the MET region the the one
that
> > Fortran code uses. But seems it doesn't do it correctly. Could you
help
> to
> > check the constants_pdef.py to see where is the problem?
> >
> > Thanks,
> >
> > Xinxia
> >
> >
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Thu May 25 08:56:17 2017
Xinxia,
Sorry we did not make this explicitly clear in the README. The data
in
*track_data* are the original files from EMC. They are in a modified
ATCF
file format and won't work with MET or with whatever scripts Minna
helped
you with. The data in *track_data_atcf* is the result of a
reprocessing
script to put the data into ATCF file format that is used by the
National
Hurricane Center and is what MET reads. You should modify a file in
track_data_atcf.
Please refer to http://ftp.nhc.noaa.gov/atcf/README for a description
of
naming convention and file format. Basically, files beginning with
"a" are
forecast tracks and beginning with "b" are called "best tracks" or in
other
words the analysis/"observed" track.
Hope this helps get you going in the right direction again.
Cheers, Tara
On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I just a little confused with the track information. First, it has
two
> folders, one is track_data and another is track_data_atcf. Should I
edit
> both or just one? Then within the track_data folder, it has amlq*
and bmlq*
> files. which file should I edit And the end is from 0001 to 0280,
what does
> this mean? And when I open the file, it has many columns, could you
help me
> to find out the critical columns like timestep, lat, lon and cyclone
id?
>
> Below is the first line of amlq2014123118.gfso.0005:
>
>
> ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO, 000,
> 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000, 1011,
178,
> -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Wednesday, May 24, 2017 12:09:09 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> Tara here. Minna is out until next week, as am I, and much of our
met_help
> staff. We will look into this further next Wed or Thur.
>
> I have not had time to run through the example you and Minna are
working on
> so really don't understand how you have it set-up for debugging. If
you
> haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> track through your system (assuming this is what you refer to as the
> Fortran code) and through MET+. You could do so by deleting all
tracks
> except one from the input track files (making sure it's the same
track). I
> would suggest using your plotting package to plot both the netcdf
output of
> the Fortran code and MET+.
>
> If there's a difference between the fields extracted, then we have a
good
> place to start. If there isn't a difference, then add another track
in,
> run the two systems, compare etc...
>
> Cheers, Tara
>
> On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Minna,
> >
> >
> > I think the MET doesn't exclude the points fall outside the
boundary
> cause
> > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > possibility we exclude them successfully? Otherwise we need to
modify the
> > track file for Fortran code and Fortran code itself.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Minna Win via RT <met_help at ucar.edu>
> > Sent: Monday, May 22, 2017 6:45:16 PM
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > From what I've found thus far, it looks like the masking by region
is
> > working as expected (this uses the MET tool TC-Stat). In some
cases,
> there
> > is a point (or points) that lie outside the boundary because they
belong
> to
> > a storm track which has an init time (with lead hour =0) within
the
> > boundary (this is consistent with the -out_init_mask argument used
to do
> > the masking). The METplus code does not perform any "surgical"
removal
> of
> > these few outliers. We get even more outliers when we perform
regridding
> > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > lon,lat values and interpolates points using the nearest neighbor
> > technique. We are requesting 60 lons and 60 lats total for the
regridded
> > tiles, so if we have a few outliers, by the time we finish
regridding we
> > end up with even more points that are outside the boundary.
> >
> > Is this what you were referring to when you thought the region
wasn't
> > getting masked? I used the values in your constants_pdef.py file
and
> they
> > look OK.
> >
> > Thanks,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > wrote:
> >
> > > Hi Minna,
> > >
> > > I use the constants_pdef.py to shrink the MET region the the one
that
> > > Fortran code uses. But seems it doesn't do it correctly. Could
you help
> > to
> > > check the constants_pdef.py to see where is the problem?
> > >
> > > Thanks,
> > >
> > > Xinxia
> > >
> > >
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Thu May 25 12:24:36 2017
Hi Tara,
Right now I understand amlq is forecast and bmlq is observation. When
I open the file, there is one column: 2014120500_F000_479S_1332W_FOF
I guess it means 20141205 initiate at time step 00. Then I notice
there're tow columns: 479S, 1332W. I guess they are latitude and
longitude. they are not usual expression. Could you tell me what's the
usual expression for 479S and 1322W?
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Thursday, May 25, 2017 10:56:17 AM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
Sorry we did not make this explicitly clear in the README. The data
in
*track_data* are the original files from EMC. They are in a modified
ATCF
file format and won't work with MET or with whatever scripts Minna
helped
you with. The data in *track_data_atcf* is the result of a
reprocessing
script to put the data into ATCF file format that is used by the
National
Hurricane Center and is what MET reads. You should modify a file in
track_data_atcf.
Please refer to http://ftp.nhc.noaa.gov/atcf/README for a description
of
naming convention and file format. Basically, files beginning with
"a" are
forecast tracks and beginning with "b" are called "best tracks" or in
other
words the analysis/"observed" track.
Hope this helps get you going in the right direction again.
Cheers, Tara
On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I just a little confused with the track information. First, it has
two
> folders, one is track_data and another is track_data_atcf. Should I
edit
> both or just one? Then within the track_data folder, it has amlq*
and bmlq*
> files. which file should I edit And the end is from 0001 to 0280,
what does
> this mean? And when I open the file, it has many columns, could you
help me
> to find out the critical columns like timestep, lat, lon and cyclone
id?
>
> Below is the first line of amlq2014123118.gfso.0005:
>
>
> ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO, 000,
> 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000, 1011,
178,
> -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Wednesday, May 24, 2017 12:09:09 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> Tara here. Minna is out until next week, as am I, and much of our
met_help
> staff. We will look into this further next Wed or Thur.
>
> I have not had time to run through the example you and Minna are
working on
> so really don't understand how you have it set-up for debugging. If
you
> haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> track through your system (assuming this is what you refer to as the
> Fortran code) and through MET+. You could do so by deleting all
tracks
> except one from the input track files (making sure it's the same
track). I
> would suggest using your plotting package to plot both the netcdf
output of
> the Fortran code and MET+.
>
> If there's a difference between the fields extracted, then we have a
good
> place to start. If there isn't a difference, then add another track
in,
> run the two systems, compare etc...
>
> Cheers, Tara
>
> On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Minna,
> >
> >
> > I think the MET doesn't exclude the points fall outside the
boundary
> cause
> > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > possibility we exclude them successfully? Otherwise we need to
modify the
> > track file for Fortran code and Fortran code itself.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Minna Win via RT <met_help at ucar.edu>
> > Sent: Monday, May 22, 2017 6:45:16 PM
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > From what I've found thus far, it looks like the masking by region
is
> > working as expected (this uses the MET tool TC-Stat). In some
cases,
> there
> > is a point (or points) that lie outside the boundary because they
belong
> to
> > a storm track which has an init time (with lead hour =0) within
the
> > boundary (this is consistent with the -out_init_mask argument used
to do
> > the masking). The METplus code does not perform any "surgical"
removal
> of
> > these few outliers. We get even more outliers when we perform
regridding
> > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > lon,lat values and interpolates points using the nearest neighbor
> > technique. We are requesting 60 lons and 60 lats total for the
regridded
> > tiles, so if we have a few outliers, by the time we finish
regridding we
> > end up with even more points that are outside the boundary.
> >
> > Is this what you were referring to when you thought the region
wasn't
> > getting masked? I used the values in your constants_pdef.py file
and
> they
> > look OK.
> >
> > Thanks,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > wrote:
> >
> > > Hi Minna,
> > >
> > > I use the constants_pdef.py to shrink the MET region the the one
that
> > > Fortran code uses. But seems it doesn't do it correctly. Could
you help
> > to
> > > check the constants_pdef.py to see where is the problem?
> > >
> > > Thanks,
> > >
> > > Xinxia
> > >
> > >
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Thu May 25 12:39:11 2017
Xinxia,
I'm sorry, I can't tell you for sure right now. Technically I'm
answering
you while I'm on vacation and right now I'm away from my computer. I
will
try to look at the file tonight.
In the meantime, I would suggest you focus your attention on lines
with ML
in the basin column. If you don't know which that is, please refer to
the
ATCF documentation I pointed you to earlier. I would cut the file
down to
one line that looks like its over US possibly and run it through the
system
and see where the extracted tile netcdf is located.
Cheers, Tara
On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
Hi Tara,
Right now I understand amlq is forecast and bmlq is observation. When
I
open the file, there is one column: 2014120500_F000_479S_1332W_FOF
I guess it means 20141205 initiate at time step 00. Then I notice
there're
tow columns: 479S, 1332W. I guess they are latitude and longitude.
they are
not usual expression. Could you tell me what's the usual expression
for
479S and 1322W?
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Thursday, May 25, 2017 10:56:17 AM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
Sorry we did not make this explicitly clear in the README. The data
in
*track_data* are the original files from EMC. They are in a modified
ATCF
file format and won't work with MET or with whatever scripts Minna
helped
you with. The data in *track_data_atcf* is the result of a
reprocessing
script to put the data into ATCF file format that is used by the
National
Hurricane Center and is what MET reads. You should modify a file in
track_data_atcf.
Please refer to http://ftp.nhc.noaa.gov/atcf/README for a description
of
naming convention and file format. Basically, files beginning with
"a" are
forecast tracks and beginning with "b" are called "best tracks" or in
other
words the analysis/"observed" track.
Hope this helps get you going in the right direction again.
Cheers, Tara
On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I just a little confused with the track information. First, it has
two
> folders, one is track_data and another is track_data_atcf. Should I
edit
> both or just one? Then within the track_data folder, it has amlq*
and
bmlq*
> files. which file should I edit And the end is from 0001 to 0280,
what
does
> this mean? And when I open the file, it has many columns, could you
help
me
> to find out the critical columns like timestep, lat, lon and cyclone
id?
>
> Below is the first line of amlq2014123118.gfso.0005:
>
>
> ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO, 000,
> 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000, 1011,
178,
> -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Wednesday, May 24, 2017 12:09:09 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> Tara here. Minna is out until next week, as am I, and much of our
met_help
> staff. We will look into this further next Wed or Thur.
>
> I have not had time to run through the example you and Minna are
working
on
> so really don't understand how you have it set-up for debugging. If
you
> haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> track through your system (assuming this is what you refer to as the
> Fortran code) and through MET+. You could do so by deleting all
tracks
> except one from the input track files (making sure it's the same
track).
I
> would suggest using your plotting package to plot both the netcdf
output
of
> the Fortran code and MET+.
>
> If there's a difference between the fields extracted, then we have a
good
> place to start. If there isn't a difference, then add another track
in,
> run the two systems, compare etc...
>
> Cheers, Tara
>
> On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Minna,
> >
> >
> > I think the MET doesn't exclude the points fall outside the
boundary
> cause
> > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > possibility we exclude them successfully? Otherwise we need to
modify
the
> > track file for Fortran code and Fortran code itself.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Minna Win via RT <met_help at ucar.edu>
> > Sent: Monday, May 22, 2017 6:45:16 PM
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > From what I've found thus far, it looks like the masking by region
is
> > working as expected (this uses the MET tool TC-Stat). In some
cases,
> there
> > is a point (or points) that lie outside the boundary because they
belong
> to
> > a storm track which has an init time (with lead hour =0) within
the
> > boundary (this is consistent with the -out_init_mask argument used
to do
> > the masking). The METplus code does not perform any "surgical"
removal
> of
> > these few outliers. We get even more outliers when we perform
regridding
> > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > lon,lat values and interpolates points using the nearest neighbor
> > technique. We are requesting 60 lons and 60 lats total for the
regridded
> > tiles, so if we have a few outliers, by the time we finish
regridding we
> > end up with even more points that are outside the boundary.
> >
> > Is this what you were referring to when you thought the region
wasn't
> > getting masked? I used the values in your constants_pdef.py file
and
> they
> > look OK.
> >
> > Thanks,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > wrote:
> >
> > > Hi Minna,
> > >
> > > I use the constants_pdef.py to shrink the MET region the the one
that
> > > Fortran code uses. But seems it doesn't do it correctly. Could
you
help
> > to
> > > check the constants_pdef.py to see where is the problem?
> > >
> > > Thanks,
> > >
> > > Xinxia
> > >
> > >
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Tue May 30 10:00:17 2017
Hi Tara,
Hope you had a wonderful vacation. I found the corresponding tracks in
MET and I deleted all other tracks information in track_data and
track_data_atcf. And in the track data of MET, I notice the minimal
pressure is around 960hPa. After I ran the software, it still has N =
600+ cases while it should have only 1. And the minimal pressure is
larger than 960hPa. I don't know where it went wrong.
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Thursday, May 25, 2017 2:39:12 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
I'm sorry, I can't tell you for sure right now. Technically I'm
answering
you while I'm on vacation and right now I'm away from my computer. I
will
try to look at the file tonight.
In the meantime, I would suggest you focus your attention on lines
with ML
in the basin column. If you don't know which that is, please refer to
the
ATCF documentation I pointed you to earlier. I would cut the file
down to
one line that looks like its over US possibly and run it through the
system
and see where the extracted tile netcdf is located.
Cheers, Tara
On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
<URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
Hi Tara,
Right now I understand amlq is forecast and bmlq is observation. When
I
open the file, there is one column: 2014120500_F000_479S_1332W_FOF
I guess it means 20141205 initiate at time step 00. Then I notice
there're
tow columns: 479S, 1332W. I guess they are latitude and longitude.
they are
not usual expression. Could you tell me what's the usual expression
for
479S and 1322W?
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Thursday, May 25, 2017 10:56:17 AM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
Sorry we did not make this explicitly clear in the README. The data
in
*track_data* are the original files from EMC. They are in a modified
ATCF
file format and won't work with MET or with whatever scripts Minna
helped
you with. The data in *track_data_atcf* is the result of a
reprocessing
script to put the data into ATCF file format that is used by the
National
Hurricane Center and is what MET reads. You should modify a file in
track_data_atcf.
Please refer to http://ftp.nhc.noaa.gov/atcf/README for a description
of
naming convention and file format. Basically, files beginning with
"a" are
forecast tracks and beginning with "b" are called "best tracks" or in
other
words the analysis/"observed" track.
Hope this helps get you going in the right direction again.
Cheers, Tara
On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I just a little confused with the track information. First, it has
two
> folders, one is track_data and another is track_data_atcf. Should I
edit
> both or just one? Then within the track_data folder, it has amlq*
and
bmlq*
> files. which file should I edit And the end is from 0001 to 0280,
what
does
> this mean? And when I open the file, it has many columns, could you
help
me
> to find out the critical columns like timestep, lat, lon and cyclone
id?
>
> Below is the first line of amlq2014123118.gfso.0005:
>
>
> ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO, 000,
> 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000, 1011,
178,
> -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Wednesday, May 24, 2017 12:09:09 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> Tara here. Minna is out until next week, as am I, and much of our
met_help
> staff. We will look into this further next Wed or Thur.
>
> I have not had time to run through the example you and Minna are
working
on
> so really don't understand how you have it set-up for debugging. If
you
> haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> track through your system (assuming this is what you refer to as the
> Fortran code) and through MET+. You could do so by deleting all
tracks
> except one from the input track files (making sure it's the same
track).
I
> would suggest using your plotting package to plot both the netcdf
output
of
> the Fortran code and MET+.
>
> If there's a difference between the fields extracted, then we have a
good
> place to start. If there isn't a difference, then add another track
in,
> run the two systems, compare etc...
>
> Cheers, Tara
>
> On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Minna,
> >
> >
> > I think the MET doesn't exclude the points fall outside the
boundary
> cause
> > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > possibility we exclude them successfully? Otherwise we need to
modify
the
> > track file for Fortran code and Fortran code itself.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Minna Win via RT <met_help at ucar.edu>
> > Sent: Monday, May 22, 2017 6:45:16 PM
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > From what I've found thus far, it looks like the masking by region
is
> > working as expected (this uses the MET tool TC-Stat). In some
cases,
> there
> > is a point (or points) that lie outside the boundary because they
belong
> to
> > a storm track which has an init time (with lead hour =0) within
the
> > boundary (this is consistent with the -out_init_mask argument used
to do
> > the masking). The METplus code does not perform any "surgical"
removal
> of
> > these few outliers. We get even more outliers when we perform
regridding
> > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > lon,lat values and interpolates points using the nearest neighbor
> > technique. We are requesting 60 lons and 60 lats total for the
regridded
> > tiles, so if we have a few outliers, by the time we finish
regridding we
> > end up with even more points that are outside the boundary.
> >
> > Is this what you were referring to when you thought the region
wasn't
> > getting masked? I used the values in your constants_pdef.py file
and
> they
> > look OK.
> >
> > Thanks,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > wrote:
> >
> > > Hi Minna,
> > >
> > > I use the constants_pdef.py to shrink the MET region the the one
that
> > > Fortran code uses. But seems it doesn't do it correctly. Could
you
help
> > to
> > > check the constants_pdef.py to see where is the problem?
> > >
> > > Thanks,
> > >
> > > Xinxia
> > >
> > >
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Thu Jun 01 16:00:51 2017
Xinxia,
Minna and I met today and noticed that when there were only 2 storm
tiles
for series_analysis for a given lead time (on 20141205_00), there was
a
listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
Sorry for delay. She just returned from time off yesterday and I
returned
today.
Cheers, Tara
On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> Hope you had a wonderful vacation. I found the corresponding tracks
in MET
> and I deleted all other tracks information in track_data and
> track_data_atcf. And in the track data of MET, I notice the minimal
> pressure is around 960hPa. After I ran the software, it still has N
= 600+
> cases while it should have only 1. And the minimal pressure is
larger than
> 960hPa. I don't know where it went wrong.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, May 25, 2017 2:39:12 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I'm sorry, I can't tell you for sure right now. Technically I'm
answering
> you while I'm on vacation and right now I'm away from my computer.
I will
> try to look at the file tonight.
>
> In the meantime, I would suggest you focus your attention on lines
with ML
> in the basin column. If you don't know which that is, please refer
to the
> ATCF documentation I pointed you to earlier. I would cut the file
down to
> one line that looks like its over US possibly and run it through the
system
> and see where the extracted tile netcdf is located.
>
> Cheers, Tara
>
>
> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> Right now I understand amlq is forecast and bmlq is observation.
When I
> open the file, there is one column: 2014120500_F000_479S_1332W_FOF
>
> I guess it means 20141205 initiate at time step 00. Then I notice
there're
> tow columns: 479S, 1332W. I guess they are latitude and longitude.
they are
> not usual expression. Could you tell me what's the usual expression
for
> 479S and 1322W?
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, May 25, 2017 10:56:17 AM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> Sorry we did not make this explicitly clear in the README. The data
in
> *track_data* are the original files from EMC. They are in a modified
ATCF
> file format and won't work with MET or with whatever scripts Minna
helped
> you with. The data in *track_data_atcf* is the result of a
reprocessing
> script to put the data into ATCF file format that is used by the
National
> Hurricane Center and is what MET reads. You should modify a file in
> track_data_atcf.
>
> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
> naming convention and file format. Basically, files beginning with
"a" are
> forecast tracks and beginning with "b" are called "best tracks" or
in other
> words the analysis/"observed" track.
>
> Hope this helps get you going in the right direction again.
> Cheers, Tara
>
>
> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > I just a little confused with the track information. First, it has
two
> > folders, one is track_data and another is track_data_atcf. Should
I edit
> > both or just one? Then within the track_data folder, it has amlq*
and
> bmlq*
> > files. which file should I edit And the end is from 0001 to 0280,
what
> does
> > this mean? And when I open the file, it has many columns, could
you help
> me
> > to find out the critical columns like timestep, lat, lon and
cyclone id?
> >
> > Below is the first line of amlq2014123118.gfso.0005:
> >
> >
> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011, 178,
> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > Tara here. Minna is out until next week, as am I, and much of our
> met_help
> > staff. We will look into this further next Wed or Thur.
> >
> > I have not had time to run through the example you and Minna are
working
> on
> > so really don't understand how you have it set-up for debugging.
If you
> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> > track through your system (assuming this is what you refer to as
the
> > Fortran code) and through MET+. You could do so by deleting all
tracks
> > except one from the input track files (making sure it's the same
track).
> I
> > would suggest using your plotting package to plot both the netcdf
output
> of
> > the Fortran code and MET+.
> >
> > If there's a difference between the fields extracted, then we have
a good
> > place to start. If there isn't a difference, then add another
track in,
> > run the two systems, compare etc...
> >
> > Cheers, Tara
> >
> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Minna,
> > >
> > >
> > > I think the MET doesn't exclude the points fall outside the
boundary
> > cause
> > > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > > possibility we exclude them successfully? Otherwise we need to
modify
> the
> > > track file for Fortran code and Fortran code itself.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Minna Win via RT <met_help at ucar.edu>
> > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Hi Xinxia,
> > >
> > > From what I've found thus far, it looks like the masking by
region is
> > > working as expected (this uses the MET tool TC-Stat). In some
cases,
> > there
> > > is a point (or points) that lie outside the boundary because
they
> belong
> > to
> > > a storm track which has an init time (with lead hour =0) within
the
> > > boundary (this is consistent with the -out_init_mask argument
used to
> do
> > > the masking). The METplus code does not perform any "surgical"
removal
> > of
> > > these few outliers. We get even more outliers when we perform
> regridding
> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > > lon,lat values and interpolates points using the nearest
neighbor
> > > technique. We are requesting 60 lons and 60 lats total for the
> regridded
> > > tiles, so if we have a few outliers, by the time we finish
regridding
> we
> > > end up with even more points that are outside the boundary.
> > >
> > > Is this what you were referring to when you thought the region
wasn't
> > > getting masked? I used the values in your constants_pdef.py
file and
> > they
> > > look OK.
> > >
> > > Thanks,
> > > Minna
> > >
> > > ---------------
> > > Minna Win
> > > NCAR
> > > Research Applications Lab
> > > Phone: 303-497-8423
> > > Fax: 302-497-8401
> > >
> > >
> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > > wrote:
> > >
> > > > Hi Minna,
> > > >
> > > > I use the constants_pdef.py to shrink the MET region the the
one that
> > > > Fortran code uses. But seems it doesn't do it correctly. Could
you
> help
> > > to
> > > > check the constants_pdef.py to see where is the problem?
> > > >
> > > > Thanks,
> > > >
> > > > Xinxia
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Fri Jun 02 13:05:00 2017
Xinxia,
I'm doing some additional testing.
Date: 20141205
Your constants_pdef.py
All tracks and data available
Results - there are two storms that meet the criteria for 00 and 06
UTC
initializations and only the one for 12 and 18 UTC inits:
In extract_tiles%
20141205_00:
filter_20141205_00.tcst ML1200152014 ML1200282014
20141205_06:
filter_20141205_06.tcst ML1200152014 ML1200282014
20141205_12:
filter_20141205_12.tcst ML1200152014
20141205_18:
filter_20141205_18.tcst ML1200152014
In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6 files
found
that match the date and lead time criteria (20141205 F000) - 4 for
ML1200152014 and 2 for ML1200282014:
-
series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_F000_gfs_4_20141205_1800_000.nc
-
series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_F000_gfs_4_20141205_0600_000.nc
-
series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_F000_gfs_4_20141205_0600_000.nc
-
series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_F000_gfs_4_20141205_0000_000.nc
-
series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_F000_gfs_4_20141205_0000_000.nc
-
series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_F000_gfs_4_20141205_1200_000.nc
In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
the series_cnt_TOTAL is listed at 6
the lats/lons appear to provide a 30 deg by 30 deg box
lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5, 29,
29.5,
30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5, 36,
36.5,
37,
37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43, 43.5,
44,
44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50, 50.5,
51,
51.5, 52, 52.5 ;
lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5, -111,
-110.5,
-110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
-105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
-100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5, -95,
-94.5,
-94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5, -89,
-88.5,
-88, -87.5, -87, -86.5, -86, -85.5 ;
So, it appears that portion of the system is working in an expected
way,
however it does not appear to allow the user to precisely focus in one
Valid time for debugging purposes. That's something we should add.
When you were doing the single track testing, did you do it in a new
directory so extract tiles would have to run again and only pull out
the
pertinent tiles? Can you send me the track file, or tell me which
track it
is that you tested and still had series_cnt_TOTAL greater than 600+?
I
really don't know how to debug it any further without without that
info.
Thanks, Tara
On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu> wrote:
> Xinxia,
>
> Minna and I met today and noticed that when there were only 2 storm
tiles
> for series_analysis for a given lead time (on 20141205_00), there
was a
> listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
>
> Sorry for delay. She just returned from time off yesterday and I
returned
> today.
>
> Cheers, Tara
>
> On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>>
>> Hi Tara,
>>
>>
>> Hope you had a wonderful vacation. I found the corresponding tracks
in
>> MET and I deleted all other tracks information in track_data and
>> track_data_atcf. And in the track data of MET, I notice the minimal
>> pressure is around 960hPa. After I ran the software, it still has N
= 600+
>> cases while it should have only 1. And the minimal pressure is
larger than
>> 960hPa. I don't know where it went wrong.
>>
>>
>> Thanks,
>>
>>
>> Xinxia
>>
>> ________________________________
>> From: Tara Jensen via RT <met_help at ucar.edu>
>> Sent: Thursday, May 25, 2017 2:39:12 PM
>> To: minnawin at ucar.edu
>> Cc: Xinxia_Song at outlook.com
>> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
>> days' worth of data based on area
>>
>> Xinxia,
>>
>> I'm sorry, I can't tell you for sure right now. Technically I'm
answering
>> you while I'm on vacation and right now I'm away from my computer.
I will
>> try to look at the file tonight.
>>
>> In the meantime, I would suggest you focus your attention on lines
with ML
>> in the basin column. If you don't know which that is, please refer
to the
>> ATCF documentation I pointed you to earlier. I would cut the file
down to
>> one line that looks like its over US possibly and run it through
the
>> system
>> and see where the extracted tile netcdf is located.
>>
>> Cheers, Tara
>>
>>
>> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>>
>> Hi Tara,
>>
>>
>> Right now I understand amlq is forecast and bmlq is observation.
When I
>> open the file, there is one column: 2014120500_F000_479S_1332W_FOF
>>
>> I guess it means 20141205 initiate at time step 00. Then I notice
there're
>> tow columns: 479S, 1332W. I guess they are latitude and longitude.
they
>> are
>> not usual expression. Could you tell me what's the usual expression
for
>> 479S and 1322W?
>>
>>
>> Thanks,
>>
>>
>> Xinxia
>>
>> ________________________________
>> From: Tara Jensen via RT <met_help at ucar.edu>
>> Sent: Thursday, May 25, 2017 10:56:17 AM
>> To: minnawin at ucar.edu
>> Cc: Xinxia_Song at outlook.com
>> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
>> days' worth of data based on area
>>
>> Xinxia,
>>
>> Sorry we did not make this explicitly clear in the README. The
data in
>> *track_data* are the original files from EMC. They are in a
modified ATCF
>> file format and won't work with MET or with whatever scripts Minna
helped
>> you with. The data in *track_data_atcf* is the result of a
reprocessing
>> script to put the data into ATCF file format that is used by the
National
>> Hurricane Center and is what MET reads. You should modify a file
in
>> track_data_atcf.
>>
>> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
>> naming convention and file format. Basically, files beginning with
"a"
>> are
>> forecast tracks and beginning with "b" are called "best tracks" or
in
>> other
>> words the analysis/"observed" track.
>>
>> Hope this helps get you going in the right direction again.
>> Cheers, Tara
>>
>>
>> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>> >
>> > Hi Tara,
>> >
>> >
>> > I just a little confused with the track information. First, it
has two
>> > folders, one is track_data and another is track_data_atcf. Should
I edit
>> > both or just one? Then within the track_data folder, it has amlq*
and
>> bmlq*
>> > files. which file should I edit And the end is from 0001 to 0280,
what
>> does
>> > this mean? And when I open the file, it has many columns, could
you help
>> me
>> > to find out the critical columns like timestep, lat, lon and
cyclone id?
>> >
>> > Below is the first line of amlq2014123118.gfso.0005:
>> >
>> >
>> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
>> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
>> 178,
>> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>> >
>> >
>> > Thanks,
>> >
>> >
>> > Xinxia
>> >
>> > ________________________________
>> > From: Tara Jensen via RT <met_help at ucar.edu>
>> > Sent: Wednesday, May 24, 2017 12:09:09 PM
>> > To: minnawin at ucar.edu
>> > Cc: Xinxia_Song at outlook.com
>> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
>> > days' worth of data based on area
>> >
>> > Hi Xinxia,
>> >
>> > Tara here. Minna is out until next week, as am I, and much of
our
>> met_help
>> > staff. We will look into this further next Wed or Thur.
>> >
>> > I have not had time to run through the example you and Minna are
working
>> on
>> > so really don't understand how you have it set-up for debugging.
If you
>> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
>> > track through your system (assuming this is what you refer to as
the
>> > Fortran code) and through MET+. You could do so by deleting all
tracks
>> > except one from the input track files (making sure it's the same
track).
>> I
>> > would suggest using your plotting package to plot both the netcdf
output
>> of
>> > the Fortran code and MET+.
>> >
>> > If there's a difference between the fields extracted, then we
have a
>> good
>> > place to start. If there isn't a difference, then add another
track in,
>> > run the two systems, compare etc...
>> >
>> > Cheers, Tara
>> >
>> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
>> > wrote:
>> >
>> > >
>> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>> > >
>> > > Hi Minna,
>> > >
>> > >
>> > > I think the MET doesn't exclude the points fall outside the
boundary
>> > cause
>> > > we have more cyclones tracked in MET than in Fortran code. Is
there
>> any
>> > > possibility we exclude them successfully? Otherwise we need to
modify
>> the
>> > > track file for Fortran code and Fortran code itself.
>> > >
>> > >
>> > > Thanks,
>> > >
>> > >
>> > > Xinxia
>> > >
>> > > ________________________________
>> > > From: Minna Win via RT <met_help at ucar.edu>
>> > > Sent: Monday, May 22, 2017 6:45:16 PM
>> > > Cc: Xinxia_Song at outlook.com
>> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
>> one
>> > > days' worth of data based on area
>> > >
>> > > Hi Xinxia,
>> > >
>> > > From what I've found thus far, it looks like the masking by
region is
>> > > working as expected (this uses the MET tool TC-Stat). In some
cases,
>> > there
>> > > is a point (or points) that lie outside the boundary because
they
>> belong
>> > to
>> > > a storm track which has an init time (with lead hour =0) within
the
>> > > boundary (this is consistent with the -out_init_mask argument
used to
>> do
>> > > the masking). The METplus code does not perform any "surgical"
>> removal
>> > of
>> > > these few outliers. We get even more outliers when we perform
>> regridding
>> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
>> > > lon,lat values and interpolates points using the nearest
neighbor
>> > > technique. We are requesting 60 lons and 60 lats total for the
>> regridded
>> > > tiles, so if we have a few outliers, by the time we finish
regridding
>> we
>> > > end up with even more points that are outside the boundary.
>> > >
>> > > Is this what you were referring to when you thought the region
wasn't
>> > > getting masked? I used the values in your constants_pdef.py
file and
>> > they
>> > > look OK.
>> > >
>> > > Thanks,
>> > > Minna
>> > >
>> > > ---------------
>> > > Minna Win
>> > > NCAR
>> > > Research Applications Lab
>> > > Phone: 303-497-8423
>> > > Fax: 302-497-8401
>> > >
>> > >
>> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com
>> >
>> > > wrote:
>> > >
>> > > > Hi Minna,
>> > > >
>> > > > I use the constants_pdef.py to shrink the MET region the the
one
>> that
>> > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
>> help
>> > > to
>> > > > check the constants_pdef.py to see where is the problem?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Xinxia
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > Tara Jensen
>> > Project Manager II
>> > NCAR RAL and DTC
>> > PO Box 3000, Boulder, Colorado 80307 USA
>> > +1 303-497-8479 jensen at ucar.edu
>> >
>> >
>> >
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Tara Jensen
>> Project Manager II
>> NCAR RAL and DTC
>> PO Box 3000, Boulder, Colorado 80307 USA
>> +1 303-497-8479 jensen at ucar.edu
>>
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 14:06:14 2017
Hi Tara,
I found in the MET/out folder has extract_tiles folder. Inside this
folder, it has output netcdf files. I think because it wasn't empty
and kept older run's results so I delete them all. Also I delete the
content within series_lead_filtered folder. Then I run METplus again,
it shows the error:
sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
serial=0)
Traceback (most recent call last):
File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 945,
in <module>
analysis_by_lead_time()
File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 326,
in analysis_by_lead_time
vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p, logger)
File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 605,
in get_netcdf_min_max
shell=True)
File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line 219,
in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
"min=min(series_cnt_TOTAL)"
/D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/series_F042_HGT_P500.nc
/D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
returned non-zero exit status 1
I attached the log files too.
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Thursday, June 1, 2017 6:00:51 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
Minna and I met today and noticed that when there were only 2 storm
tiles
for series_analysis for a given lead time (on 20141205_00), there was
a
listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
Sorry for delay. She just returned from time off yesterday and I
returned
today.
Cheers, Tara
On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> Hope you had a wonderful vacation. I found the corresponding tracks
in MET
> and I deleted all other tracks information in track_data and
> track_data_atcf. And in the track data of MET, I notice the minimal
> pressure is around 960hPa. After I ran the software, it still has N
= 600+
> cases while it should have only 1. And the minimal pressure is
larger than
> 960hPa. I don't know where it went wrong.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, May 25, 2017 2:39:12 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I'm sorry, I can't tell you for sure right now. Technically I'm
answering
> you while I'm on vacation and right now I'm away from my computer.
I will
> try to look at the file tonight.
>
> In the meantime, I would suggest you focus your attention on lines
with ML
> in the basin column. If you don't know which that is, please refer
to the
> ATCF documentation I pointed you to earlier. I would cut the file
down to
> one line that looks like its over US possibly and run it through the
system
> and see where the extracted tile netcdf is located.
>
> Cheers, Tara
>
>
> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> Right now I understand amlq is forecast and bmlq is observation.
When I
> open the file, there is one column: 2014120500_F000_479S_1332W_FOF
>
> I guess it means 20141205 initiate at time step 00. Then I notice
there're
> tow columns: 479S, 1332W. I guess they are latitude and longitude.
they are
> not usual expression. Could you tell me what's the usual expression
for
> 479S and 1322W?
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, May 25, 2017 10:56:17 AM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> Sorry we did not make this explicitly clear in the README. The data
in
> *track_data* are the original files from EMC. They are in a modified
ATCF
> file format and won't work with MET or with whatever scripts Minna
helped
> you with. The data in *track_data_atcf* is the result of a
reprocessing
> script to put the data into ATCF file format that is used by the
National
> Hurricane Center and is what MET reads. You should modify a file in
> track_data_atcf.
>
> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
> naming convention and file format. Basically, files beginning with
"a" are
> forecast tracks and beginning with "b" are called "best tracks" or
in other
> words the analysis/"observed" track.
>
> Hope this helps get you going in the right direction again.
> Cheers, Tara
>
>
> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > I just a little confused with the track information. First, it has
two
> > folders, one is track_data and another is track_data_atcf. Should
I edit
> > both or just one? Then within the track_data folder, it has amlq*
and
> bmlq*
> > files. which file should I edit And the end is from 0001 to 0280,
what
> does
> > this mean? And when I open the file, it has many columns, could
you help
> me
> > to find out the critical columns like timestep, lat, lon and
cyclone id?
> >
> > Below is the first line of amlq2014123118.gfso.0005:
> >
> >
> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011, 178,
> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Hi Xinxia,
> >
> > Tara here. Minna is out until next week, as am I, and much of our
> met_help
> > staff. We will look into this further next Wed or Thur.
> >
> > I have not had time to run through the example you and Minna are
working
> on
> > so really don't understand how you have it set-up for debugging.
If you
> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> > track through your system (assuming this is what you refer to as
the
> > Fortran code) and through MET+. You could do so by deleting all
tracks
> > except one from the input track files (making sure it's the same
track).
> I
> > would suggest using your plotting package to plot both the netcdf
output
> of
> > the Fortran code and MET+.
> >
> > If there's a difference between the fields extracted, then we have
a good
> > place to start. If there isn't a difference, then add another
track in,
> > run the two systems, compare etc...
> >
> > Cheers, Tara
> >
> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Minna,
> > >
> > >
> > > I think the MET doesn't exclude the points fall outside the
boundary
> > cause
> > > we have more cyclones tracked in MET than in Fortran code. Is
there any
> > > possibility we exclude them successfully? Otherwise we need to
modify
> the
> > > track file for Fortran code and Fortran code itself.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Minna Win via RT <met_help at ucar.edu>
> > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Hi Xinxia,
> > >
> > > From what I've found thus far, it looks like the masking by
region is
> > > working as expected (this uses the MET tool TC-Stat). In some
cases,
> > there
> > > is a point (or points) that lie outside the boundary because
they
> belong
> > to
> > > a storm track which has an init time (with lead hour =0) within
the
> > > boundary (this is consistent with the -out_init_mask argument
used to
> do
> > > the masking). The METplus code does not perform any "surgical"
removal
> > of
> > > these few outliers. We get even more outliers when we perform
> regridding
> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > > lon,lat values and interpolates points using the nearest
neighbor
> > > technique. We are requesting 60 lons and 60 lats total for the
> regridded
> > > tiles, so if we have a few outliers, by the time we finish
regridding
> we
> > > end up with even more points that are outside the boundary.
> > >
> > > Is this what you were referring to when you thought the region
wasn't
> > > getting masked? I used the values in your constants_pdef.py
file and
> > they
> > > look OK.
> > >
> > > Thanks,
> > > Minna
> > >
> > > ---------------
> > > Minna Win
> > > NCAR
> > > Research Applications Lab
> > > Phone: 303-497-8423
> > > Fax: 302-497-8401
> > >
> > >
> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com>
> > > wrote:
> > >
> > > > Hi Minna,
> > > >
> > > > I use the constants_pdef.py to shrink the MET region the the
one that
> > > > Fortran code uses. But seems it doesn't do it correctly. Could
you
> help
> > > to
> > > > check the constants_pdef.py to see where is the problem?
> > > >
> > > > Thanks,
> > > >
> > > > Xinxia
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Fri Jun 02 14:27:54 2017
Hi Xinxia,
That is a strange error especially since you have completed a MET+ run
before. I would suggest you change your OUTPUT_BASE in
constants_pdef.py
to be a different directory name and start "fresh". That's what I do
for
testing. Also, make sure your disk is not full.
Cheers, Tara
On Fri, Jun 2, 2017 at 2:06 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I found in the MET/out folder has extract_tiles folder. Inside this
> folder, it has output netcdf files. I think because it wasn't empty
and
> kept older run's results so I delete them all. Also I delete the
content
> within series_lead_filtered folder. Then I run METplus again, it
shows the
> error:
>
>
> sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
> serial=0)
>
> Traceback (most recent call last):
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 945,
in
> <module>
>
> analysis_by_lead_time()
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 326,
in
> analysis_by_lead_time
>
> vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p,
logger)
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 605,
in
> get_netcdf_min_max
>
> shell=True)
>
> File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line
219, in
> check_output
>
> raise CalledProcessError(retcode, cmd, output=output)
>
> subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
> "min=min(series_cnt_TOTAL)" /D2/xinxia/METplus/MET/out/
> series_analysis_lead/series_F042/series_F042_HGT_P500.nc
> /D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
> returned non-zero exit status 1
>
>
> I attached the log files too.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, June 1, 2017 6:00:51 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> Minna and I met today and noticed that when there were only 2 storm
tiles
> for series_analysis for a given lead time (on 20141205_00), there
was a
> listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
>
> Sorry for delay. She just returned from time off yesterday and I
returned
> today.
>
> Cheers, Tara
>
> On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > Hope you had a wonderful vacation. I found the corresponding
tracks in
> MET
> > and I deleted all other tracks information in track_data and
> > track_data_atcf. And in the track data of MET, I notice the
minimal
> > pressure is around 960hPa. After I ran the software, it still has
N =
> 600+
> > cases while it should have only 1. And the minimal pressure is
larger
> than
> > 960hPa. I don't know where it went wrong.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, May 25, 2017 2:39:12 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > I'm sorry, I can't tell you for sure right now. Technically I'm
answering
> > you while I'm on vacation and right now I'm away from my computer.
I
> will
> > try to look at the file tonight.
> >
> > In the meantime, I would suggest you focus your attention on lines
with
> ML
> > in the basin column. If you don't know which that is, please refer
to the
> > ATCF documentation I pointed you to earlier. I would cut the file
down
> to
> > one line that looks like its over US possibly and run it through
the
> system
> > and see where the extracted tile netcdf is located.
> >
> > Cheers, Tara
> >
> >
> > On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
> >
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > Right now I understand amlq is forecast and bmlq is observation.
When I
> > open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> >
> > I guess it means 20141205 initiate at time step 00. Then I notice
> there're
> > tow columns: 479S, 1332W. I guess they are latitude and longitude.
they
> are
> > not usual expression. Could you tell me what's the usual
expression for
> > 479S and 1322W?
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, May 25, 2017 10:56:17 AM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > Sorry we did not make this explicitly clear in the README. The
data in
> > *track_data* are the original files from EMC. They are in a
modified ATCF
> > file format and won't work with MET or with whatever scripts Minna
helped
> > you with. The data in *track_data_atcf* is the result of a
reprocessing
> > script to put the data into ATCF file format that is used by the
National
> > Hurricane Center and is what MET reads. You should modify a file
in
> > track_data_atcf.
> >
> > Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
> > naming convention and file format. Basically, files beginning
with "a"
> are
> > forecast tracks and beginning with "b" are called "best tracks" or
in
> other
> > words the analysis/"observed" track.
> >
> > Hope this helps get you going in the right direction again.
> > Cheers, Tara
> >
> >
> > On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > I just a little confused with the track information. First, it
has two
> > > folders, one is track_data and another is track_data_atcf.
Should I
> edit
> > > both or just one? Then within the track_data folder, it has
amlq* and
> > bmlq*
> > > files. which file should I edit And the end is from 0001 to
0280, what
> > does
> > > this mean? And when I open the file, it has many columns, could
you
> help
> > me
> > > to find out the critical columns like timestep, lat, lon and
cyclone
> id?
> > >
> > > Below is the first line of amlq2014123118.gfso.0005:
> > >
> > >
> > > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> > > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> 178,
> > > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Hi Xinxia,
> > >
> > > Tara here. Minna is out until next week, as am I, and much of
our
> > met_help
> > > staff. We will look into this further next Wed or Thur.
> > >
> > > I have not had time to run through the example you and Minna are
> working
> > on
> > > so really don't understand how you have it set-up for debugging.
If
> you
> > > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> > > track through your system (assuming this is what you refer to as
the
> > > Fortran code) and through MET+. You could do so by deleting all
tracks
> > > except one from the input track files (making sure it's the same
> track).
> > I
> > > would suggest using your plotting package to plot both the
netcdf
> output
> > of
> > > the Fortran code and MET+.
> > >
> > > If there's a difference between the fields extracted, then we
have a
> good
> > > place to start. If there isn't a difference, then add another
track
> in,
> > > run the two systems, compare etc...
> > >
> > > Cheers, Tara
> > >
> > > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >
> > > > Hi Minna,
> > > >
> > > >
> > > > I think the MET doesn't exclude the points fall outside the
boundary
> > > cause
> > > > we have more cyclones tracked in MET than in Fortran code. Is
there
> any
> > > > possibility we exclude them successfully? Otherwise we need to
modify
> > the
> > > > track file for Fortran code and Fortran code itself.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Xinxia
> > > >
> > > > ________________________________
> > > > From: Minna Win via RT <met_help at ucar.edu>
> > > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > > Cc: Xinxia_Song at outlook.com
> > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > > > days' worth of data based on area
> > > >
> > > > Hi Xinxia,
> > > >
> > > > From what I've found thus far, it looks like the masking by
region is
> > > > working as expected (this uses the MET tool TC-Stat). In some
cases,
> > > there
> > > > is a point (or points) that lie outside the boundary because
they
> > belong
> > > to
> > > > a storm track which has an init time (with lead hour =0)
within the
> > > > boundary (this is consistent with the -out_init_mask argument
used to
> > do
> > > > the masking). The METplus code does not perform any
"surgical"
> removal
> > > of
> > > > these few outliers. We get even more outliers when we perform
> > regridding
> > > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > > > lon,lat values and interpolates points using the nearest
neighbor
> > > > technique. We are requesting 60 lons and 60 lats total for
the
> > regridded
> > > > tiles, so if we have a few outliers, by the time we finish
regridding
> > we
> > > > end up with even more points that are outside the boundary.
> > > >
> > > > Is this what you were referring to when you thought the region
wasn't
> > > > getting masked? I used the values in your constants_pdef.py
file and
> > > they
> > > > look OK.
> > > >
> > > > Thanks,
> > > > Minna
> > > >
> > > > ---------------
> > > > Minna Win
> > > > NCAR
> > > > Research Applications Lab
> > > > Phone: 303-497-8423
> > > > Fax: 302-497-8401
> > > >
> > > >
> > > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> Xinxia_Song at outlook.com>
> > > > wrote:
> > > >
> > > > > Hi Minna,
> > > > >
> > > > > I use the constants_pdef.py to shrink the MET region the the
one
> that
> > > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
> > help
> > > > to
> > > > > check the constants_pdef.py to see where is the problem?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Xinxia
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 15:17:13 2017
Hi Tara,
Thanks for your suggestion now it works.
But there is still something strange. In 20141205_00, it has two
cyclones tracked one's id is ML1200152014 and another's is
ML1200282014. I deleted all other cyclone track information and
ML1200152014's track information. But the output in extract_tiles and
series_analysis_lead still has ML1200152014's output. And the cases
counted is 6.
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 4:27:55 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Xinxia,
That is a strange error especially since you have completed a MET+ run
before. I would suggest you change your OUTPUT_BASE in
constants_pdef.py
to be a different directory name and start "fresh". That's what I do
for
testing. Also, make sure your disk is not full.
Cheers, Tara
On Fri, Jun 2, 2017 at 2:06 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> I found in the MET/out folder has extract_tiles folder. Inside this
> folder, it has output netcdf files. I think because it wasn't empty
and
> kept older run's results so I delete them all. Also I delete the
content
> within series_lead_filtered folder. Then I run METplus again, it
shows the
> error:
>
>
> sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
> serial=0)
>
> Traceback (most recent call last):
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 945,
in
> <module>
>
> analysis_by_lead_time()
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 326,
in
> analysis_by_lead_time
>
> vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p,
logger)
>
> File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line 605,
in
> get_netcdf_min_max
>
> shell=True)
>
> File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line
219, in
> check_output
>
> raise CalledProcessError(retcode, cmd, output=output)
>
> subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
> "min=min(series_cnt_TOTAL)" /D2/xinxia/METplus/MET/out/
> series_analysis_lead/series_F042/series_F042_HGT_P500.nc
> /D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
> returned non-zero exit status 1
>
>
> I attached the log files too.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Thursday, June 1, 2017 6:00:51 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> Minna and I met today and noticed that when there were only 2 storm
tiles
> for series_analysis for a given lead time (on 20141205_00), there
was a
> listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
>
> Sorry for delay. She just returned from time off yesterday and I
returned
> today.
>
> Cheers, Tara
>
> On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > Hope you had a wonderful vacation. I found the corresponding
tracks in
> MET
> > and I deleted all other tracks information in track_data and
> > track_data_atcf. And in the track data of MET, I notice the
minimal
> > pressure is around 960hPa. After I ran the software, it still has
N =
> 600+
> > cases while it should have only 1. And the minimal pressure is
larger
> than
> > 960hPa. I don't know where it went wrong.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, May 25, 2017 2:39:12 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > I'm sorry, I can't tell you for sure right now. Technically I'm
answering
> > you while I'm on vacation and right now I'm away from my computer.
I
> will
> > try to look at the file tonight.
> >
> > In the meantime, I would suggest you focus your attention on lines
with
> ML
> > in the basin column. If you don't know which that is, please refer
to the
> > ATCF documentation I pointed you to earlier. I would cut the file
down
> to
> > one line that looks like its over US possibly and run it through
the
> system
> > and see where the extracted tile netcdf is located.
> >
> > Cheers, Tara
> >
> >
> > On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
> >
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > Right now I understand amlq is forecast and bmlq is observation.
When I
> > open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> >
> > I guess it means 20141205 initiate at time step 00. Then I notice
> there're
> > tow columns: 479S, 1332W. I guess they are latitude and longitude.
they
> are
> > not usual expression. Could you tell me what's the usual
expression for
> > 479S and 1322W?
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, May 25, 2017 10:56:17 AM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > Sorry we did not make this explicitly clear in the README. The
data in
> > *track_data* are the original files from EMC. They are in a
modified ATCF
> > file format and won't work with MET or with whatever scripts Minna
helped
> > you with. The data in *track_data_atcf* is the result of a
reprocessing
> > script to put the data into ATCF file format that is used by the
National
> > Hurricane Center and is what MET reads. You should modify a file
in
> > track_data_atcf.
> >
> > Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
> > naming convention and file format. Basically, files beginning
with "a"
> are
> > forecast tracks and beginning with "b" are called "best tracks" or
in
> other
> > words the analysis/"observed" track.
> >
> > Hope this helps get you going in the right direction again.
> > Cheers, Tara
> >
> >
> > On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > I just a little confused with the track information. First, it
has two
> > > folders, one is track_data and another is track_data_atcf.
Should I
> edit
> > > both or just one? Then within the track_data folder, it has
amlq* and
> > bmlq*
> > > files. which file should I edit And the end is from 0001 to
0280, what
> > does
> > > this mean? And when I open the file, it has many columns, could
you
> help
> > me
> > > to find out the critical columns like timestep, lat, lon and
cyclone
> id?
> > >
> > > Below is the first line of amlq2014123118.gfso.0005:
> > >
> > >
> > > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> > > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> 178,
> > > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Hi Xinxia,
> > >
> > > Tara here. Minna is out until next week, as am I, and much of
our
> > met_help
> > > staff. We will look into this further next Wed or Thur.
> > >
> > > I have not had time to run through the example you and Minna are
> working
> > on
> > > so really don't understand how you have it set-up for debugging.
If
> you
> > > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> > > track through your system (assuming this is what you refer to as
the
> > > Fortran code) and through MET+. You could do so by deleting all
tracks
> > > except one from the input track files (making sure it's the same
> track).
> > I
> > > would suggest using your plotting package to plot both the
netcdf
> output
> > of
> > > the Fortran code and MET+.
> > >
> > > If there's a difference between the fields extracted, then we
have a
> good
> > > place to start. If there isn't a difference, then add another
track
> in,
> > > run the two systems, compare etc...
> > >
> > > Cheers, Tara
> > >
> > > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >
> > > > Hi Minna,
> > > >
> > > >
> > > > I think the MET doesn't exclude the points fall outside the
boundary
> > > cause
> > > > we have more cyclones tracked in MET than in Fortran code. Is
there
> any
> > > > possibility we exclude them successfully? Otherwise we need to
modify
> > the
> > > > track file for Fortran code and Fortran code itself.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Xinxia
> > > >
> > > > ________________________________
> > > > From: Minna Win via RT <met_help at ucar.edu>
> > > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > > Cc: Xinxia_Song at outlook.com
> > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > > > days' worth of data based on area
> > > >
> > > > Hi Xinxia,
> > > >
> > > > From what I've found thus far, it looks like the masking by
region is
> > > > working as expected (this uses the MET tool TC-Stat). In some
cases,
> > > there
> > > > is a point (or points) that lie outside the boundary because
they
> > belong
> > > to
> > > > a storm track which has an init time (with lead hour =0)
within the
> > > > boundary (this is consistent with the -out_init_mask argument
used to
> > do
> > > > the masking). The METplus code does not perform any
"surgical"
> removal
> > > of
> > > > these few outliers. We get even more outliers when we perform
> > regridding
> > > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> > > > lon,lat values and interpolates points using the nearest
neighbor
> > > > technique. We are requesting 60 lons and 60 lats total for
the
> > regridded
> > > > tiles, so if we have a few outliers, by the time we finish
regridding
> > we
> > > > end up with even more points that are outside the boundary.
> > > >
> > > > Is this what you were referring to when you thought the region
wasn't
> > > > getting masked? I used the values in your constants_pdef.py
file and
> > > they
> > > > look OK.
> > > >
> > > > Thanks,
> > > > Minna
> > > >
> > > > ---------------
> > > > Minna Win
> > > > NCAR
> > > > Research Applications Lab
> > > > Phone: 303-497-8423
> > > > Fax: 302-497-8401
> > > >
> > > >
> > > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> Xinxia_Song at outlook.com>
> > > > wrote:
> > > >
> > > > > Hi Minna,
> > > > >
> > > > > I use the constants_pdef.py to shrink the MET region the the
one
> that
> > > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
> > help
> > > > to
> > > > > check the constants_pdef.py to see where is the problem?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Xinxia
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Fri Jun 02 15:26:30 2017
Hi Xinxia,
What you got is exactly what I got when I ran the package (scroll down
and
read my second-to-last email). I am confused as to what you were
using for
the track. Based on your email:
"I deleted all other cyclone track information and ML1200152014's
track
information. But the output in extract_tiles and series_analysis_lead
still
has ML1200152014's output."
it seems you were trying to run with a track file that only had the
ML1200282014 track in it. It that correct?
Can you send me the track file you are trying to debug with? I'd like
to
recreate what you're seeing.
Thanks, Tara
On Fri, Jun 2, 2017 at 3:17 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
> Thanks for your suggestion now it works.
>
> But there is still something strange. In 20141205_00, it has two
cyclones
> tracked one's id is ML1200152014 and another's is ML1200282014. I
deleted
> all other cyclone track information and ML1200152014's track
information.
> But the output in extract_tiles and series_analysis_lead still has
> ML1200152014's output. And the cases counted is 6.
>
> Thanks,
>
> Xinxia
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 4:27:55 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> That is a strange error especially since you have completed a MET+
run
> before. I would suggest you change your OUTPUT_BASE in
constants_pdef.py
> to be a different directory name and start "fresh". That's what I
do for
> testing. Also, make sure your disk is not full.
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 2:06 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > I found in the MET/out folder has extract_tiles folder. Inside
this
> > folder, it has output netcdf files. I think because it wasn't
empty and
> > kept older run's results so I delete them all. Also I delete the
content
> > within series_lead_filtered folder. Then I run METplus again, it
shows
> the
> > error:
> >
> >
> > sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
> > serial=0)
> >
> > Traceback (most recent call last):
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
945, in
> > <module>
> >
> > analysis_by_lead_time()
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
326, in
> > analysis_by_lead_time
> >
> > vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p,
logger)
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
605, in
> > get_netcdf_min_max
> >
> > shell=True)
> >
> > File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line
219,
> in
> > check_output
> >
> > raise CalledProcessError(retcode, cmd, output=output)
> >
> > subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
> > "min=min(series_cnt_TOTAL)" /D2/xinxia/METplus/MET/out/
> > series_analysis_lead/series_F042/series_F042_HGT_P500.nc
> >
/D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
> > returned non-zero exit status 1
> >
> >
> > I attached the log files too.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, June 1, 2017 6:00:51 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > Minna and I met today and noticed that when there were only 2
storm tiles
> > for series_analysis for a given lead time (on 20141205_00), there
was a
> > listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
> >
> > Sorry for delay. She just returned from time off yesterday and I
> returned
> > today.
> >
> > Cheers, Tara
> >
> > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Hope you had a wonderful vacation. I found the corresponding
tracks in
> > MET
> > > and I deleted all other tracks information in track_data and
> > > track_data_atcf. And in the track data of MET, I notice the
minimal
> > > pressure is around 960hPa. After I ran the software, it still
has N =
> > 600+
> > > cases while it should have only 1. And the minimal pressure is
larger
> > than
> > > 960hPa. I don't know where it went wrong.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 2:39:12 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > I'm sorry, I can't tell you for sure right now. Technically I'm
> answering
> > > you while I'm on vacation and right now I'm away from my
computer. I
> > will
> > > try to look at the file tonight.
> > >
> > > In the meantime, I would suggest you focus your attention on
lines with
> > ML
> > > in the basin column. If you don't know which that is, please
refer to
> the
> > > ATCF documentation I pointed you to earlier. I would cut the
file down
> > to
> > > one line that looks like its over US possibly and run it through
the
> > system
> > > and see where the extracted tile netcdf is located.
> > >
> > > Cheers, Tara
> > >
> > >
> > > On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> wrote:
> > >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Right now I understand amlq is forecast and bmlq is observation.
When I
> > > open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > >
> > > I guess it means 20141205 initiate at time step 00. Then I
notice
> > there're
> > > tow columns: 479S, 1332W. I guess they are latitude and
longitude. they
> > are
> > > not usual expression. Could you tell me what's the usual
expression for
> > > 479S and 1322W?
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 10:56:17 AM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > Sorry we did not make this explicitly clear in the README. The
data in
> > > *track_data* are the original files from EMC. They are in a
modified
> ATCF
> > > file format and won't work with MET or with whatever scripts
Minna
> helped
> > > you with. The data in *track_data_atcf* is the result of a
reprocessing
> > > script to put the data into ATCF file format that is used by the
> National
> > > Hurricane Center and is what MET reads. You should modify a
file in
> > > track_data_atcf.
> > >
> > > Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> of
> > > naming convention and file format. Basically, files beginning
with "a"
> > are
> > > forecast tracks and beginning with "b" are called "best tracks"
or in
> > other
> > > words the analysis/"observed" track.
> > >
> > > Hope this helps get you going in the right direction again.
> > > Cheers, Tara
> > >
> > >
> > > On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >
> > > > Hi Tara,
> > > >
> > > >
> > > > I just a little confused with the track information. First, it
has
> two
> > > > folders, one is track_data and another is track_data_atcf.
Should I
> > edit
> > > > both or just one? Then within the track_data folder, it has
amlq* and
> > > bmlq*
> > > > files. which file should I edit And the end is from 0001 to
0280,
> what
> > > does
> > > > this mean? And when I open the file, it has many columns,
could you
> > help
> > > me
> > > > to find out the critical columns like timestep, lat, lon and
cyclone
> > id?
> > > >
> > > > Below is the first line of amlq2014123118.gfso.0005:
> > > >
> > > >
> > > > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO, 000,
> > > > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> > 178,
> > > > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Xinxia
> > > >
> > > > ________________________________
> > > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > > To: minnawin at ucar.edu
> > > > Cc: Xinxia_Song at outlook.com
> > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > > > days' worth of data based on area
> > > >
> > > > Hi Xinxia,
> > > >
> > > > Tara here. Minna is out until next week, as am I, and much of
our
> > > met_help
> > > > staff. We will look into this further next Wed or Thur.
> > > >
> > > > I have not had time to run through the example you and Minna
are
> > working
> > > on
> > > > so really don't understand how you have it set-up for
debugging. If
> > you
> > > > haven't done so yet, I'd suggest running just 1 extra tropical
> cyclone
> > > > track through your system (assuming this is what you refer to
as the
> > > > Fortran code) and through MET+. You could do so by deleting
all
> tracks
> > > > except one from the input track files (making sure it's the
same
> > track).
> > > I
> > > > would suggest using your plotting package to plot both the
netcdf
> > output
> > > of
> > > > the Fortran code and MET+.
> > > >
> > > > If there's a difference between the fields extracted, then we
have a
> > good
> > > > place to start. If there isn't a difference, then add another
track
> > in,
> > > > run the two systems, compare etc...
> > > >
> > > > Cheers, Tara
> > > >
> > > > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > > > >
> > > > > Hi Minna,
> > > > >
> > > > >
> > > > > I think the MET doesn't exclude the points fall outside the
> boundary
> > > > cause
> > > > > we have more cyclones tracked in MET than in Fortran code.
Is there
> > any
> > > > > possibility we exclude them successfully? Otherwise we need
to
> modify
> > > the
> > > > > track file for Fortran code and Fortran code itself.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > Xinxia
> > > > >
> > > > > ________________________________
> > > > > From: Minna Win via RT <met_help at ucar.edu>
> > > > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > > > Cc: Xinxia_Song at outlook.com
> > > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > > > > days' worth of data based on area
> > > > >
> > > > > Hi Xinxia,
> > > > >
> > > > > From what I've found thus far, it looks like the masking by
region
> is
> > > > > working as expected (this uses the MET tool TC-Stat). In
some
> cases,
> > > > there
> > > > > is a point (or points) that lie outside the boundary because
they
> > > belong
> > > > to
> > > > > a storm track which has an init time (with lead hour =0)
within the
> > > > > boundary (this is consistent with the -out_init_mask
argument used
> to
> > > do
> > > > > the masking). The METplus code does not perform any
"surgical"
> > removal
> > > > of
> > > > > these few outliers. We get even more outliers when we
perform
> > > regridding
> > > > > with the MET tool regrid_data_plane. This uses the atrack
and
> btrack
> > > > > lon,lat values and interpolates points using the nearest
neighbor
> > > > > technique. We are requesting 60 lons and 60 lats total for
the
> > > regridded
> > > > > tiles, so if we have a few outliers, by the time we finish
> regridding
> > > we
> > > > > end up with even more points that are outside the boundary.
> > > > >
> > > > > Is this what you were referring to when you thought the
region
> wasn't
> > > > > getting masked? I used the values in your constants_pdef.py
file
> and
> > > > they
> > > > > look OK.
> > > > >
> > > > > Thanks,
> > > > > Minna
> > > > >
> > > > > ---------------
> > > > > Minna Win
> > > > > NCAR
> > > > > Research Applications Lab
> > > > > Phone: 303-497-8423
> > > > > Fax: 302-497-8401
> > > > >
> > > > >
> > > > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > Xinxia_Song at outlook.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Minna,
> > > > > >
> > > > > > I use the constants_pdef.py to shrink the MET region the
the one
> > that
> > > > > > Fortran code uses. But seems it doesn't do it correctly.
Could
> you
> > > help
> > > > > to
> > > > > > check the constants_pdef.py to see where is the problem?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Xinxia
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Tara Jensen
> > > > Project Manager II
> > > > NCAR RAL and DTC
> > > > PO Box 3000, Boulder, Colorado 80307 USA
> > > > +1 303-497-8479 jensen at ucar.edu
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 15:31:41 2017
Hi Tara,
Attached is the track file.
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 5:26:30 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Xinxia,
What you got is exactly what I got when I ran the package (scroll down
and
read my second-to-last email). I am confused as to what you were
using for
the track. Based on your email:
"I deleted all other cyclone track information and ML1200152014's
track
information. But the output in extract_tiles and series_analysis_lead
still
has ML1200152014's output."
it seems you were trying to run with a track file that only had the
ML1200282014 track in it. It that correct?
Can you send me the track file you are trying to debug with? I'd like
to
recreate what you're seeing.
Thanks, Tara
On Fri, Jun 2, 2017 at 3:17 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
> Thanks for your suggestion now it works.
>
> But there is still something strange. In 20141205_00, it has two
cyclones
> tracked one's id is ML1200152014 and another's is ML1200282014. I
deleted
> all other cyclone track information and ML1200152014's track
information.
> But the output in extract_tiles and series_analysis_lead still has
> ML1200152014's output. And the cases counted is 6.
>
> Thanks,
>
> Xinxia
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 4:27:55 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> That is a strange error especially since you have completed a MET+
run
> before. I would suggest you change your OUTPUT_BASE in
constants_pdef.py
> to be a different directory name and start "fresh". That's what I
do for
> testing. Also, make sure your disk is not full.
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 2:06 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > I found in the MET/out folder has extract_tiles folder. Inside
this
> > folder, it has output netcdf files. I think because it wasn't
empty and
> > kept older run's results so I delete them all. Also I delete the
content
> > within series_lead_filtered folder. Then I run METplus again, it
shows
> the
> > error:
> >
> >
> > sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
> > serial=0)
> >
> > Traceback (most recent call last):
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
945, in
> > <module>
> >
> > analysis_by_lead_time()
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
326, in
> > analysis_by_lead_time
> >
> > vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p,
logger)
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
605, in
> > get_netcdf_min_max
> >
> > shell=True)
> >
> > File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line
219,
> in
> > check_output
> >
> > raise CalledProcessError(retcode, cmd, output=output)
> >
> > subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
> > "min=min(series_cnt_TOTAL)" /D2/xinxia/METplus/MET/out/
> > series_analysis_lead/series_F042/series_F042_HGT_P500.nc
> >
/D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
> > returned non-zero exit status 1
> >
> >
> > I attached the log files too.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, June 1, 2017 6:00:51 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > Minna and I met today and noticed that when there were only 2
storm tiles
> > for series_analysis for a given lead time (on 20141205_00), there
was a
> > listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
> >
> > Sorry for delay. She just returned from time off yesterday and I
> returned
> > today.
> >
> > Cheers, Tara
> >
> > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Hope you had a wonderful vacation. I found the corresponding
tracks in
> > MET
> > > and I deleted all other tracks information in track_data and
> > > track_data_atcf. And in the track data of MET, I notice the
minimal
> > > pressure is around 960hPa. After I ran the software, it still
has N =
> > 600+
> > > cases while it should have only 1. And the minimal pressure is
larger
> > than
> > > 960hPa. I don't know where it went wrong.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 2:39:12 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > I'm sorry, I can't tell you for sure right now. Technically I'm
> answering
> > > you while I'm on vacation and right now I'm away from my
computer. I
> > will
> > > try to look at the file tonight.
> > >
> > > In the meantime, I would suggest you focus your attention on
lines with
> > ML
> > > in the basin column. If you don't know which that is, please
refer to
> the
> > > ATCF documentation I pointed you to earlier. I would cut the
file down
> > to
> > > one line that looks like its over US possibly and run it through
the
> > system
> > > and see where the extracted tile netcdf is located.
> > >
> > > Cheers, Tara
> > >
> > >
> > > On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> wrote:
> > >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Right now I understand amlq is forecast and bmlq is observation.
When I
> > > open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > >
> > > I guess it means 20141205 initiate at time step 00. Then I
notice
> > there're
> > > tow columns: 479S, 1332W. I guess they are latitude and
longitude. they
> > are
> > > not usual expression. Could you tell me what's the usual
expression for
> > > 479S and 1322W?
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 10:56:17 AM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > Sorry we did not make this explicitly clear in the README. The
data in
> > > *track_data* are the original files from EMC. They are in a
modified
> ATCF
> > > file format and won't work with MET or with whatever scripts
Minna
> helped
> > > you with. The data in *track_data_atcf* is the result of a
reprocessing
> > > script to put the data into ATCF file format that is used by the
> National
> > > Hurricane Center and is what MET reads. You should modify a
file in
> > > track_data_atcf.
> > >
> > > Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> of
> > > naming convention and file format. Basically, files beginning
with "a"
> > are
> > > forecast tracks and beginning with "b" are called "best tracks"
or in
> > other
> > > words the analysis/"observed" track.
> > >
> > > Hope this helps get you going in the right direction again.
> > > Cheers, Tara
> > >
> > >
> > > On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >
> > > > Hi Tara,
> > > >
> > > >
> > > > I just a little confused with the track information. First, it
has
> two
> > > > folders, one is track_data and another is track_data_atcf.
Should I
> > edit
> > > > both or just one? Then within the track_data folder, it has
amlq* and
> > > bmlq*
> > > > files. which file should I edit And the end is from 0001 to
0280,
> what
> > > does
> > > > this mean? And when I open the file, it has many columns,
could you
> > help
> > > me
> > > > to find out the critical columns like timestep, lat, lon and
cyclone
> > id?
> > > >
> > > > Below is the first line of amlq2014123118.gfso.0005:
> > > >
> > > >
> > > > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO, 000,
> > > > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> > 178,
> > > > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Xinxia
> > > >
> > > > ________________________________
> > > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > > To: minnawin at ucar.edu
> > > > Cc: Xinxia_Song at outlook.com
> > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > > > days' worth of data based on area
> > > >
> > > > Hi Xinxia,
> > > >
> > > > Tara here. Minna is out until next week, as am I, and much of
our
> > > met_help
> > > > staff. We will look into this further next Wed or Thur.
> > > >
> > > > I have not had time to run through the example you and Minna
are
> > working
> > > on
> > > > so really don't understand how you have it set-up for
debugging. If
> > you
> > > > haven't done so yet, I'd suggest running just 1 extra tropical
> cyclone
> > > > track through your system (assuming this is what you refer to
as the
> > > > Fortran code) and through MET+. You could do so by deleting
all
> tracks
> > > > except one from the input track files (making sure it's the
same
> > track).
> > > I
> > > > would suggest using your plotting package to plot both the
netcdf
> > output
> > > of
> > > > the Fortran code and MET+.
> > > >
> > > > If there's a difference between the fields extracted, then we
have a
> > good
> > > > place to start. If there isn't a difference, then add another
track
> > in,
> > > > run the two systems, compare etc...
> > > >
> > > > Cheers, Tara
> > > >
> > > > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > > > >
> > > > > Hi Minna,
> > > > >
> > > > >
> > > > > I think the MET doesn't exclude the points fall outside the
> boundary
> > > > cause
> > > > > we have more cyclones tracked in MET than in Fortran code.
Is there
> > any
> > > > > possibility we exclude them successfully? Otherwise we need
to
> modify
> > > the
> > > > > track file for Fortran code and Fortran code itself.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > Xinxia
> > > > >
> > > > > ________________________________
> > > > > From: Minna Win via RT <met_help at ucar.edu>
> > > > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > > > Cc: Xinxia_Song at outlook.com
> > > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > > > > days' worth of data based on area
> > > > >
> > > > > Hi Xinxia,
> > > > >
> > > > > From what I've found thus far, it looks like the masking by
region
> is
> > > > > working as expected (this uses the MET tool TC-Stat). In
some
> cases,
> > > > there
> > > > > is a point (or points) that lie outside the boundary because
they
> > > belong
> > > > to
> > > > > a storm track which has an init time (with lead hour =0)
within the
> > > > > boundary (this is consistent with the -out_init_mask
argument used
> to
> > > do
> > > > > the masking). The METplus code does not perform any
"surgical"
> > removal
> > > > of
> > > > > these few outliers. We get even more outliers when we
perform
> > > regridding
> > > > > with the MET tool regrid_data_plane. This uses the atrack
and
> btrack
> > > > > lon,lat values and interpolates points using the nearest
neighbor
> > > > > technique. We are requesting 60 lons and 60 lats total for
the
> > > regridded
> > > > > tiles, so if we have a few outliers, by the time we finish
> regridding
> > > we
> > > > > end up with even more points that are outside the boundary.
> > > > >
> > > > > Is this what you were referring to when you thought the
region
> wasn't
> > > > > getting masked? I used the values in your constants_pdef.py
file
> and
> > > > they
> > > > > look OK.
> > > > >
> > > > > Thanks,
> > > > > Minna
> > > > >
> > > > > ---------------
> > > > > Minna Win
> > > > > NCAR
> > > > > Research Applications Lab
> > > > > Phone: 303-497-8423
> > > > > Fax: 302-497-8401
> > > > >
> > > > >
> > > > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > Xinxia_Song at outlook.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Minna,
> > > > > >
> > > > > > I use the constants_pdef.py to shrink the MET region the
the one
> > that
> > > > > > Fortran code uses. But seems it doesn't do it correctly.
Could
> you
> > > help
> > > > > to
> > > > > > check the constants_pdef.py to see where is the problem?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Xinxia
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Tara Jensen
> > > > Project Manager II
> > > > NCAR RAL and DTC
> > > > PO Box 3000, Boulder, Colorado 80307 USA
> > > > +1 303-497-8479 jensen at ucar.edu
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 15:32:52 2017
And yes, I'm trying to run with a track file that only had the
ML1200282014 track in it.
________________________________
From: Xinxia Song
Sent: Friday, June 2, 2017 5:31:37 PM
To: met_help at ucar.edu
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Tara,
Attached is the track file.
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 5:26:30 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Hi Xinxia,
What you got is exactly what I got when I ran the package (scroll down
and
read my second-to-last email). I am confused as to what you were
using for
the track. Based on your email:
"I deleted all other cyclone track information and ML1200152014's
track
information. But the output in extract_tiles and series_analysis_lead
still
has ML1200152014's output."
it seems you were trying to run with a track file that only had the
ML1200282014 track in it. It that correct?
Can you send me the track file you are trying to debug with? I'd like
to
recreate what you're seeing.
Thanks, Tara
On Fri, Jun 2, 2017 at 3:17 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
> Thanks for your suggestion now it works.
>
> But there is still something strange. In 20141205_00, it has two
cyclones
> tracked one's id is ML1200152014 and another's is ML1200282014. I
deleted
> all other cyclone track information and ML1200152014's track
information.
> But the output in extract_tiles and series_analysis_lead still has
> ML1200152014's output. And the cases counted is 6.
>
> Thanks,
>
> Xinxia
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 4:27:55 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Hi Xinxia,
>
> That is a strange error especially since you have completed a MET+
run
> before. I would suggest you change your OUTPUT_BASE in
constants_pdef.py
> to be a different directory name and start "fresh". That's what I
do for
> testing. Also, make sure your disk is not full.
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 2:06 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > I found in the MET/out folder has extract_tiles folder. Inside
this
> > folder, it has output netcdf files. I think because it wasn't
empty and
> > kept older run's results so I delete them all. Also I delete the
content
> > within series_lead_filtered folder. Then I run METplus again, it
shows
> the
> > error:
> >
> >
> > sys.version_info(major=2, minor=7, micro=13, releaselevel='final',
> > serial=0)
> >
> > Traceback (most recent call last):
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
945, in
> > <module>
> >
> > analysis_by_lead_time()
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
326, in
> > analysis_by_lead_time
> >
> > vmin, vmax = get_netcdf_min_max(nc_var_list, cur_stat, p,
logger)
> >
> > File "/D2/xinxia/METplus/METplus/ush/series_by_lead.py", line
605, in
> > get_netcdf_min_max
> >
> > shell=True)
> >
> > File "/home/xinxia/anaconda2/lib/python2.7/subprocess.py", line
219,
> in
> > check_output
> >
> > raise CalledProcessError(retcode, cmd, output=output)
> >
> > subprocess.CalledProcessError: Command '/usr/bin/ncap2 -v -s
> > "min=min(series_cnt_TOTAL)" /D2/xinxia/METplus/MET/out/
> > series_analysis_lead/series_F042/series_F042_HGT_P500.nc
> >
/D2/xinxia/METplus/MET/out/series_analysis_lead/series_F042/min.nc'
> > returned non-zero exit status 1
> >
> >
> > I attached the log files too.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Thursday, June 1, 2017 6:00:51 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > Minna and I met today and noticed that when there were only 2
storm tiles
> > for series_analysis for a given lead time (on 20141205_00), there
was a
> > listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
> >
> > Sorry for delay. She just returned from time off yesterday and I
> returned
> > today.
> >
> > Cheers, Tara
> >
> > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Hope you had a wonderful vacation. I found the corresponding
tracks in
> > MET
> > > and I deleted all other tracks information in track_data and
> > > track_data_atcf. And in the track data of MET, I notice the
minimal
> > > pressure is around 960hPa. After I ran the software, it still
has N =
> > 600+
> > > cases while it should have only 1. And the minimal pressure is
larger
> > than
> > > 960hPa. I don't know where it went wrong.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 2:39:12 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > I'm sorry, I can't tell you for sure right now. Technically I'm
> answering
> > > you while I'm on vacation and right now I'm away from my
computer. I
> > will
> > > try to look at the file tonight.
> > >
> > > In the meantime, I would suggest you focus your attention on
lines with
> > ML
> > > in the basin column. If you don't know which that is, please
refer to
> the
> > > ATCF documentation I pointed you to earlier. I would cut the
file down
> > to
> > > one line that looks like its over US possibly and run it through
the
> > system
> > > and see where the extracted tile netcdf is located.
> > >
> > > Cheers, Tara
> > >
> > >
> > > On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> wrote:
> > >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > Right now I understand amlq is forecast and bmlq is observation.
When I
> > > open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > >
> > > I guess it means 20141205 initiate at time step 00. Then I
notice
> > there're
> > > tow columns: 479S, 1332W. I guess they are latitude and
longitude. they
> > are
> > > not usual expression. Could you tell me what's the usual
expression for
> > > 479S and 1322W?
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Thursday, May 25, 2017 10:56:17 AM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > Sorry we did not make this explicitly clear in the README. The
data in
> > > *track_data* are the original files from EMC. They are in a
modified
> ATCF
> > > file format and won't work with MET or with whatever scripts
Minna
> helped
> > > you with. The data in *track_data_atcf* is the result of a
reprocessing
> > > script to put the data into ATCF file format that is used by the
> National
> > > Hurricane Center and is what MET reads. You should modify a
file in
> > > track_data_atcf.
> > >
> > > Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> of
> > > naming convention and file format. Basically, files beginning
with "a"
> > are
> > > forecast tracks and beginning with "b" are called "best tracks"
or in
> > other
> > > words the analysis/"observed" track.
> > >
> > > Hope this helps get you going in the right direction again.
> > > Cheers, Tara
> > >
> > >
> > > On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >
> > > > Hi Tara,
> > > >
> > > >
> > > > I just a little confused with the track information. First, it
has
> two
> > > > folders, one is track_data and another is track_data_atcf.
Should I
> > edit
> > > > both or just one? Then within the track_data folder, it has
amlq* and
> > > bmlq*
> > > > files. which file should I edit And the end is from 0001 to
0280,
> what
> > > does
> > > > this mean? And when I open the file, it has many columns,
could you
> > help
> > > me
> > > > to find out the critical columns like timestep, lat, lon and
cyclone
> > id?
> > > >
> > > > Below is the first line of amlq2014123118.gfso.0005:
> > > >
> > > >
> > > > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO, 000,
> > > > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> > 178,
> > > > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Xinxia
> > > >
> > > > ________________________________
> > > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > > To: minnawin at ucar.edu
> > > > Cc: Xinxia_Song at outlook.com
> > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > > > days' worth of data based on area
> > > >
> > > > Hi Xinxia,
> > > >
> > > > Tara here. Minna is out until next week, as am I, and much of
our
> > > met_help
> > > > staff. We will look into this further next Wed or Thur.
> > > >
> > > > I have not had time to run through the example you and Minna
are
> > working
> > > on
> > > > so really don't understand how you have it set-up for
debugging. If
> > you
> > > > haven't done so yet, I'd suggest running just 1 extra tropical
> cyclone
> > > > track through your system (assuming this is what you refer to
as the
> > > > Fortran code) and through MET+. You could do so by deleting
all
> tracks
> > > > except one from the input track files (making sure it's the
same
> > track).
> > > I
> > > > would suggest using your plotting package to plot both the
netcdf
> > output
> > > of
> > > > the Fortran code and MET+.
> > > >
> > > > If there's a difference between the fields extracted, then we
have a
> > good
> > > > place to start. If there isn't a difference, then add another
track
> > in,
> > > > run the two systems, compare etc...
> > > >
> > > > Cheers, Tara
> > > >
> > > > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > > > >
> > > > > Hi Minna,
> > > > >
> > > > >
> > > > > I think the MET doesn't exclude the points fall outside the
> boundary
> > > > cause
> > > > > we have more cyclones tracked in MET than in Fortran code.
Is there
> > any
> > > > > possibility we exclude them successfully? Otherwise we need
to
> modify
> > > the
> > > > > track file for Fortran code and Fortran code itself.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > Xinxia
> > > > >
> > > > > ________________________________
> > > > > From: Minna Win via RT <met_help at ucar.edu>
> > > > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > > > Cc: Xinxia_Song at outlook.com
> > > > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > > > > days' worth of data based on area
> > > > >
> > > > > Hi Xinxia,
> > > > >
> > > > > From what I've found thus far, it looks like the masking by
region
> is
> > > > > working as expected (this uses the MET tool TC-Stat). In
some
> cases,
> > > > there
> > > > > is a point (or points) that lie outside the boundary because
they
> > > belong
> > > > to
> > > > > a storm track which has an init time (with lead hour =0)
within the
> > > > > boundary (this is consistent with the -out_init_mask
argument used
> to
> > > do
> > > > > the masking). The METplus code does not perform any
"surgical"
> > removal
> > > > of
> > > > > these few outliers. We get even more outliers when we
perform
> > > regridding
> > > > > with the MET tool regrid_data_plane. This uses the atrack
and
> btrack
> > > > > lon,lat values and interpolates points using the nearest
neighbor
> > > > > technique. We are requesting 60 lons and 60 lats total for
the
> > > regridded
> > > > > tiles, so if we have a few outliers, by the time we finish
> regridding
> > > we
> > > > > end up with even more points that are outside the boundary.
> > > > >
> > > > > Is this what you were referring to when you thought the
region
> wasn't
> > > > > getting masked? I used the values in your constants_pdef.py
file
> and
> > > > they
> > > > > look OK.
> > > > >
> > > > > Thanks,
> > > > > Minna
> > > > >
> > > > > ---------------
> > > > > Minna Win
> > > > > NCAR
> > > > > Research Applications Lab
> > > > > Phone: 303-497-8423
> > > > > Fax: 302-497-8401
> > > > >
> > > > >
> > > > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > Xinxia_Song at outlook.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Minna,
> > > > > >
> > > > > > I use the constants_pdef.py to shrink the MET region the
the one
> > that
> > > > > > Fortran code uses. But seems it doesn't do it correctly.
Could
> you
> > > help
> > > > > to
> > > > > > check the constants_pdef.py to see where is the problem?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Xinxia
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Tara Jensen
> > > > Project Manager II
> > > > NCAR RAL and DTC
> > > > PO Box 3000, Boulder, Colorado 80307 USA
> > > > +1 303-497-8479 jensen at ucar.edu
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 17:56:29 2017
Hi Tara,
The 600+ results are because I ran the MET before with 2 months and
the output is kept. When I run a single day, it doesn't overwrite the
output but keeps them so it has 600+ cases counted.
Right now I think to compare the MET and Fortran, we could only
compare a single day's composite.
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 3:05:00 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
I'm doing some additional testing.
Date: 20141205
Your constants_pdef.py
All tracks and data available
Results - there are two storms that meet the criteria for 00 and 06
UTC
initializations and only the one for 12 and 18 UTC inits:
In extract_tiles%
20141205_00:
filter_20141205_00.tcst ML1200152014 ML1200282014
20141205_06:
filter_20141205_06.tcst ML1200152014 ML1200282014
20141205_12:
filter_20141205_12.tcst ML1200152014
20141205_18:
filter_20141205_18.tcst ML1200152014
In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6 files
found
that match the date and lead time criteria (20141205 F000) - 4 for
ML1200152014 and 2 for ML1200282014:
-
series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_F000_gfs_4_20141205_1800_000.nc
-
series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_F000_gfs_4_20141205_0600_000.nc
-
series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_F000_gfs_4_20141205_0600_000.nc
-
series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_F000_gfs_4_20141205_0000_000.nc
-
series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_F000_gfs_4_20141205_0000_000.nc
-
series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_F000_gfs_4_20141205_1200_000.nc
In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
the series_cnt_TOTAL is listed at 6
the lats/lons appear to provide a 30 deg by 30 deg box
lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5, 29,
29.5,
30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5, 36,
36.5,
37,
37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43, 43.5,
44,
44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50, 50.5,
51,
51.5, 52, 52.5 ;
lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5, -111,
-110.5,
-110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
-105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
-100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5, -95,
-94.5,
-94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5, -89,
-88.5,
-88, -87.5, -87, -86.5, -86, -85.5 ;
So, it appears that portion of the system is working in an expected
way,
however it does not appear to allow the user to precisely focus in one
Valid time for debugging purposes. That's something we should add.
When you were doing the single track testing, did you do it in a new
directory so extract tiles would have to run again and only pull out
the
pertinent tiles? Can you send me the track file, or tell me which
track it
is that you tested and still had series_cnt_TOTAL greater than 600+?
I
really don't know how to debug it any further without without that
info.
Thanks, Tara
On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu> wrote:
> Xinxia,
>
> Minna and I met today and noticed that when there were only 2 storm
tiles
> for series_analysis for a given lead time (on 20141205_00), there
was a
> listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
>
> Sorry for delay. She just returned from time off yesterday and I
returned
> today.
>
> Cheers, Tara
>
> On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>>
>> Hi Tara,
>>
>>
>> Hope you had a wonderful vacation. I found the corresponding tracks
in
>> MET and I deleted all other tracks information in track_data and
>> track_data_atcf. And in the track data of MET, I notice the minimal
>> pressure is around 960hPa. After I ran the software, it still has N
= 600+
>> cases while it should have only 1. And the minimal pressure is
larger than
>> 960hPa. I don't know where it went wrong.
>>
>>
>> Thanks,
>>
>>
>> Xinxia
>>
>> ________________________________
>> From: Tara Jensen via RT <met_help at ucar.edu>
>> Sent: Thursday, May 25, 2017 2:39:12 PM
>> To: minnawin at ucar.edu
>> Cc: Xinxia_Song at outlook.com
>> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
>> days' worth of data based on area
>>
>> Xinxia,
>>
>> I'm sorry, I can't tell you for sure right now. Technically I'm
answering
>> you while I'm on vacation and right now I'm away from my computer.
I will
>> try to look at the file tonight.
>>
>> In the meantime, I would suggest you focus your attention on lines
with ML
>> in the basin column. If you don't know which that is, please refer
to the
>> ATCF documentation I pointed you to earlier. I would cut the file
down to
>> one line that looks like its over US possibly and run it through
the
>> system
>> and see where the extracted tile netcdf is located.
>>
>> Cheers, Tara
>>
>>
>> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
wrote:
>>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>>
>> Hi Tara,
>>
>>
>> Right now I understand amlq is forecast and bmlq is observation.
When I
>> open the file, there is one column: 2014120500_F000_479S_1332W_FOF
>>
>> I guess it means 20141205 initiate at time step 00. Then I notice
there're
>> tow columns: 479S, 1332W. I guess they are latitude and longitude.
they
>> are
>> not usual expression. Could you tell me what's the usual expression
for
>> 479S and 1322W?
>>
>>
>> Thanks,
>>
>>
>> Xinxia
>>
>> ________________________________
>> From: Tara Jensen via RT <met_help at ucar.edu>
>> Sent: Thursday, May 25, 2017 10:56:17 AM
>> To: minnawin at ucar.edu
>> Cc: Xinxia_Song at outlook.com
>> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
>> days' worth of data based on area
>>
>> Xinxia,
>>
>> Sorry we did not make this explicitly clear in the README. The
data in
>> *track_data* are the original files from EMC. They are in a
modified ATCF
>> file format and won't work with MET or with whatever scripts Minna
helped
>> you with. The data in *track_data_atcf* is the result of a
reprocessing
>> script to put the data into ATCF file format that is used by the
National
>> Hurricane Center and is what MET reads. You should modify a file
in
>> track_data_atcf.
>>
>> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description of
>> naming convention and file format. Basically, files beginning with
"a"
>> are
>> forecast tracks and beginning with "b" are called "best tracks" or
in
>> other
>> words the analysis/"observed" track.
>>
>> Hope this helps get you going in the right direction again.
>> Cheers, Tara
>>
>>
>> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>> >
>> > Hi Tara,
>> >
>> >
>> > I just a little confused with the track information. First, it
has two
>> > folders, one is track_data and another is track_data_atcf. Should
I edit
>> > both or just one? Then within the track_data folder, it has amlq*
and
>> bmlq*
>> > files. which file should I edit And the end is from 0001 to 0280,
what
>> does
>> > this mean? And when I open the file, it has many columns, could
you help
>> me
>> > to find out the critical columns like timestep, lat, lon and
cyclone id?
>> >
>> > Below is the first line of amlq2014123118.gfso.0005:
>> >
>> >
>> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
>> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
>> 178,
>> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
>> >
>> >
>> > Thanks,
>> >
>> >
>> > Xinxia
>> >
>> > ________________________________
>> > From: Tara Jensen via RT <met_help at ucar.edu>
>> > Sent: Wednesday, May 24, 2017 12:09:09 PM
>> > To: minnawin at ucar.edu
>> > Cc: Xinxia_Song at outlook.com
>> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
>> > days' worth of data based on area
>> >
>> > Hi Xinxia,
>> >
>> > Tara here. Minna is out until next week, as am I, and much of
our
>> met_help
>> > staff. We will look into this further next Wed or Thur.
>> >
>> > I have not had time to run through the example you and Minna are
working
>> on
>> > so really don't understand how you have it set-up for debugging.
If you
>> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
>> > track through your system (assuming this is what you refer to as
the
>> > Fortran code) and through MET+. You could do so by deleting all
tracks
>> > except one from the input track files (making sure it's the same
track).
>> I
>> > would suggest using your plotting package to plot both the netcdf
output
>> of
>> > the Fortran code and MET+.
>> >
>> > If there's a difference between the fields extracted, then we
have a
>> good
>> > place to start. If there isn't a difference, then add another
track in,
>> > run the two systems, compare etc...
>> >
>> > Cheers, Tara
>> >
>> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT
<met_help at ucar.edu>
>> > wrote:
>> >
>> > >
>> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>> > >
>> > > Hi Minna,
>> > >
>> > >
>> > > I think the MET doesn't exclude the points fall outside the
boundary
>> > cause
>> > > we have more cyclones tracked in MET than in Fortran code. Is
there
>> any
>> > > possibility we exclude them successfully? Otherwise we need to
modify
>> the
>> > > track file for Fortran code and Fortran code itself.
>> > >
>> > >
>> > > Thanks,
>> > >
>> > >
>> > > Xinxia
>> > >
>> > > ________________________________
>> > > From: Minna Win via RT <met_help at ucar.edu>
>> > > Sent: Monday, May 22, 2017 6:45:16 PM
>> > > Cc: Xinxia_Song at outlook.com
>> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
>> one
>> > > days' worth of data based on area
>> > >
>> > > Hi Xinxia,
>> > >
>> > > From what I've found thus far, it looks like the masking by
region is
>> > > working as expected (this uses the MET tool TC-Stat). In some
cases,
>> > there
>> > > is a point (or points) that lie outside the boundary because
they
>> belong
>> > to
>> > > a storm track which has an init time (with lead hour =0) within
the
>> > > boundary (this is consistent with the -out_init_mask argument
used to
>> do
>> > > the masking). The METplus code does not perform any "surgical"
>> removal
>> > of
>> > > these few outliers. We get even more outliers when we perform
>> regridding
>> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
>> > > lon,lat values and interpolates points using the nearest
neighbor
>> > > technique. We are requesting 60 lons and 60 lats total for the
>> regridded
>> > > tiles, so if we have a few outliers, by the time we finish
regridding
>> we
>> > > end up with even more points that are outside the boundary.
>> > >
>> > > Is this what you were referring to when you thought the region
wasn't
>> > > getting masked? I used the values in your constants_pdef.py
file and
>> > they
>> > > look OK.
>> > >
>> > > Thanks,
>> > > Minna
>> > >
>> > > ---------------
>> > > Minna Win
>> > > NCAR
>> > > Research Applications Lab
>> > > Phone: 303-497-8423
>> > > Fax: 302-497-8401
>> > >
>> > >
>> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song
<Xinxia_Song at outlook.com
>> >
>> > > wrote:
>> > >
>> > > > Hi Minna,
>> > > >
>> > > > I use the constants_pdef.py to shrink the MET region the the
one
>> that
>> > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
>> help
>> > > to
>> > > > check the constants_pdef.py to see where is the problem?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Xinxia
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > Tara Jensen
>> > Project Manager II
>> > NCAR RAL and DTC
>> > PO Box 3000, Boulder, Colorado 80307 USA
>> > +1 303-497-8479 jensen at ucar.edu
>> >
>> >
>> >
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Tara Jensen
>> Project Manager II
>> NCAR RAL and DTC
>> PO Box 3000, Boulder, Colorado 80307 USA
>> +1 303-497-8479 jensen at ucar.edu
>>
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Fri Jun 02 18:13:13 2017
Xinxia,
I agree testing with one day is a good place to start, then add
another and
another until we are confident it is working properly. I'm working on
setting up a test with your 1 track and am honestly surprised to see
that
MET+ is retaining the track. Storm 0028 appears to be at 60N and
higher
and thus is outside your region - which according to the netcdf file
is 23N
to 53N. Is this the correct region of interest?
Cheers, Tara
On Fri, Jun 2, 2017 at 5:56 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> The 600+ results are because I ran the MET before with 2 months and
the
> output is kept. When I run a single day, it doesn't overwrite the
output
> but keeps them so it has 600+ cases counted.
>
>
> Right now I think to compare the MET and Fortran, we could only
compare a
> single day's composite.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 3:05:00 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I'm doing some additional testing.
>
> Date: 20141205
> Your constants_pdef.py
> All tracks and data available
>
> Results - there are two storms that meet the criteria for 00 and 06
UTC
> initializations and only the one for 12 and 18 UTC inits:
>
> In extract_tiles%
> 20141205_00:
> filter_20141205_00.tcst ML1200152014 ML1200282014
> 20141205_06:
> filter_20141205_06.tcst ML1200152014 ML1200282014
> 20141205_12:
> filter_20141205_12.tcst ML1200152014
> 20141205_18:
> filter_20141205_18.tcst ML1200152014
>
> In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6
files
> found
> that match the date and lead time criteria (20141205 F000) - 4 for
> ML1200152014 and 2 for ML1200282014:
>
> -
> series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_1800_000.nc
> -
> series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_0600_000.nc
> -
> series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_
> F000_gfs_4_20141205_0600_000.nc
> -
> series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_0000_000.nc
> -
> series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_
> F000_gfs_4_20141205_0000_000.nc
> -
> series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_1200_000.nc
>
> In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
> the series_cnt_TOTAL is listed at 6
> the lats/lons appear to provide a 30 deg by 30 deg box
>
> lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5,
29,
> 29.5,
> 30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5, 36,
36.5,
> 37,
> 37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43,
43.5, 44,
> 44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50,
50.5, 51,
> 51.5, 52, 52.5 ;
>
> lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5, -111,
> -110.5,
> -110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
> -105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
> -100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5,
-95,
> -94.5,
> -94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5, -89,
-88.5,
> -88, -87.5, -87, -86.5, -86, -85.5 ;
>
> So, it appears that portion of the system is working in an expected
way,
> however it does not appear to allow the user to precisely focus in
one
> Valid time for debugging purposes. That's something we should add.
>
> When you were doing the single track testing, did you do it in a new
> directory so extract tiles would have to run again and only pull out
the
> pertinent tiles? Can you send me the track file, or tell me which
track it
> is that you tested and still had series_cnt_TOTAL greater than 600+?
I
> really don't know how to debug it any further without without that
info.
>
> Thanks, Tara
>
>
>
> On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu> wrote:
>
> > Xinxia,
> >
> > Minna and I met today and noticed that when there were only 2
storm tiles
> > for series_analysis for a given lead time (on 20141205_00), there
was a
> > listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
> >
> > Sorry for delay. She just returned from time off yesterday and I
> returned
> > today.
> >
> > Cheers, Tara
> >
> > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >>
> >> Hi Tara,
> >>
> >>
> >> Hope you had a wonderful vacation. I found the corresponding
tracks in
> >> MET and I deleted all other tracks information in track_data and
> >> track_data_atcf. And in the track data of MET, I notice the
minimal
> >> pressure is around 960hPa. After I ran the software, it still has
N =
> 600+
> >> cases while it should have only 1. And the minimal pressure is
larger
> than
> >> 960hPa. I don't know where it went wrong.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Xinxia
> >>
> >> ________________________________
> >> From: Tara Jensen via RT <met_help at ucar.edu>
> >> Sent: Thursday, May 25, 2017 2:39:12 PM
> >> To: minnawin at ucar.edu
> >> Cc: Xinxia_Song at outlook.com
> >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> >> days' worth of data based on area
> >>
> >> Xinxia,
> >>
> >> I'm sorry, I can't tell you for sure right now. Technically I'm
> answering
> >> you while I'm on vacation and right now I'm away from my
computer. I
> will
> >> try to look at the file tonight.
> >>
> >> In the meantime, I would suggest you focus your attention on
lines with
> ML
> >> in the basin column. If you don't know which that is, please
refer to
> the
> >> ATCF documentation I pointed you to earlier. I would cut the
file down
> to
> >> one line that looks like its over US possibly and run it through
the
> >> system
> >> and see where the extracted tile netcdf is located.
> >>
> >> Cheers, Tara
> >>
> >>
> >> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
> wrote:
> >>
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >>
> >> Hi Tara,
> >>
> >>
> >> Right now I understand amlq is forecast and bmlq is observation.
When I
> >> open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> >>
> >> I guess it means 20141205 initiate at time step 00. Then I notice
> there're
> >> tow columns: 479S, 1332W. I guess they are latitude and
longitude. they
> >> are
> >> not usual expression. Could you tell me what's the usual
expression for
> >> 479S and 1322W?
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Xinxia
> >>
> >> ________________________________
> >> From: Tara Jensen via RT <met_help at ucar.edu>
> >> Sent: Thursday, May 25, 2017 10:56:17 AM
> >> To: minnawin at ucar.edu
> >> Cc: Xinxia_Song at outlook.com
> >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> >> days' worth of data based on area
> >>
> >> Xinxia,
> >>
> >> Sorry we did not make this explicitly clear in the README. The
data in
> >> *track_data* are the original files from EMC. They are in a
modified
> ATCF
> >> file format and won't work with MET or with whatever scripts
Minna
> helped
> >> you with. The data in *track_data_atcf* is the result of a
reprocessing
> >> script to put the data into ATCF file format that is used by the
> National
> >> Hurricane Center and is what MET reads. You should modify a file
in
> >> track_data_atcf.
> >>
> >> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> of
> >> naming convention and file format. Basically, files beginning
with "a"
> >> are
> >> forecast tracks and beginning with "b" are called "best tracks"
or in
> >> other
> >> words the analysis/"observed" track.
> >>
> >> Hope this helps get you going in the right direction again.
> >> Cheers, Tara
> >>
> >>
> >> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu
> >
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >> >
> >> > Hi Tara,
> >> >
> >> >
> >> > I just a little confused with the track information. First, it
has two
> >> > folders, one is track_data and another is track_data_atcf.
Should I
> edit
> >> > both or just one? Then within the track_data folder, it has
amlq* and
> >> bmlq*
> >> > files. which file should I edit And the end is from 0001 to
0280, what
> >> does
> >> > this mean? And when I open the file, it has many columns, could
you
> help
> >> me
> >> > to find out the critical columns like timestep, lat, lon and
cyclone
> id?
> >> >
> >> > Below is the first line of amlq2014123118.gfso.0005:
> >> >
> >> >
> >> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> >> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> >> 178,
> >> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> >> >
> >> >
> >> > Thanks,
> >> >
> >> >
> >> > Xinxia
> >> >
> >> > ________________________________
> >> > From: Tara Jensen via RT <met_help at ucar.edu>
> >> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> >> > To: minnawin at ucar.edu
> >> > Cc: Xinxia_Song at outlook.com
> >> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> >> > days' worth of data based on area
> >> >
> >> > Hi Xinxia,
> >> >
> >> > Tara here. Minna is out until next week, as am I, and much of
our
> >> met_help
> >> > staff. We will look into this further next Wed or Thur.
> >> >
> >> > I have not had time to run through the example you and Minna
are
> working
> >> on
> >> > so really don't understand how you have it set-up for
debugging. If
> you
> >> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> >> > track through your system (assuming this is what you refer to
as the
> >> > Fortran code) and through MET+. You could do so by deleting
all
> tracks
> >> > except one from the input track files (making sure it's the
same
> track).
> >> I
> >> > would suggest using your plotting package to plot both the
netcdf
> output
> >> of
> >> > the Fortran code and MET+.
> >> >
> >> > If there's a difference between the fields extracted, then we
have a
> >> good
> >> > place to start. If there isn't a difference, then add another
track
> in,
> >> > run the two systems, compare etc...
> >> >
> >> > Cheers, Tara
> >> >
> >> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> met_help at ucar.edu>
> >> > wrote:
> >> >
> >> > >
> >> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> >> > >
> >> > > Hi Minna,
> >> > >
> >> > >
> >> > > I think the MET doesn't exclude the points fall outside the
boundary
> >> > cause
> >> > > we have more cyclones tracked in MET than in Fortran code. Is
there
> >> any
> >> > > possibility we exclude them successfully? Otherwise we need
to
> modify
> >> the
> >> > > track file for Fortran code and Fortran code itself.
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > >
> >> > > Xinxia
> >> > >
> >> > > ________________________________
> >> > > From: Minna Win via RT <met_help at ucar.edu>
> >> > > Sent: Monday, May 22, 2017 6:45:16 PM
> >> > > Cc: Xinxia_Song at outlook.com
> >> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> >> one
> >> > > days' worth of data based on area
> >> > >
> >> > > Hi Xinxia,
> >> > >
> >> > > From what I've found thus far, it looks like the masking by
region
> is
> >> > > working as expected (this uses the MET tool TC-Stat). In
some
> cases,
> >> > there
> >> > > is a point (or points) that lie outside the boundary because
they
> >> belong
> >> > to
> >> > > a storm track which has an init time (with lead hour =0)
within the
> >> > > boundary (this is consistent with the -out_init_mask argument
used
> to
> >> do
> >> > > the masking). The METplus code does not perform any
"surgical"
> >> removal
> >> > of
> >> > > these few outliers. We get even more outliers when we
perform
> >> regridding
> >> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> >> > > lon,lat values and interpolates points using the nearest
neighbor
> >> > > technique. We are requesting 60 lons and 60 lats total for
the
> >> regridded
> >> > > tiles, so if we have a few outliers, by the time we finish
> regridding
> >> we
> >> > > end up with even more points that are outside the boundary.
> >> > >
> >> > > Is this what you were referring to when you thought the
region
> wasn't
> >> > > getting masked? I used the values in your constants_pdef.py
file
> and
> >> > they
> >> > > look OK.
> >> > >
> >> > > Thanks,
> >> > > Minna
> >> > >
> >> > > ---------------
> >> > > Minna Win
> >> > > NCAR
> >> > > Research Applications Lab
> >> > > Phone: 303-497-8423
> >> > > Fax: 302-497-8401
> >> > >
> >> > >
> >> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> Xinxia_Song at outlook.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Hi Minna,
> >> > > >
> >> > > > I use the constants_pdef.py to shrink the MET region the
the one
> >> that
> >> > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
> >> help
> >> > > to
> >> > > > check the constants_pdef.py to see where is the problem?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Xinxia
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> > Tara Jensen
> >> > Project Manager II
> >> > NCAR RAL and DTC
> >> > PO Box 3000, Boulder, Colorado 80307 USA
> >> > +1 303-497-8479 jensen at ucar.edu
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Tara Jensen
> >> Project Manager II
> >> NCAR RAL and DTC
> >> PO Box 3000, Boulder, Colorado 80307 USA
> >> +1 303-497-8479 jensen at ucar.edu
> >>
> >>
> >>
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
> >
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Fri Jun 02 18:15:33 2017
Hi Tara,
The region is 25N-65N, 260E-320E
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 8:13:13 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
I agree testing with one day is a good place to start, then add
another and
another until we are confident it is working properly. I'm working on
setting up a test with your 1 track and am honestly surprised to see
that
MET+ is retaining the track. Storm 0028 appears to be at 60N and
higher
and thus is outside your region - which according to the netcdf file
is 23N
to 53N. Is this the correct region of interest?
Cheers, Tara
On Fri, Jun 2, 2017 at 5:56 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> The 600+ results are because I ran the MET before with 2 months and
the
> output is kept. When I run a single day, it doesn't overwrite the
output
> but keeps them so it has 600+ cases counted.
>
>
> Right now I think to compare the MET and Fortran, we could only
compare a
> single day's composite.
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 3:05:00 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I'm doing some additional testing.
>
> Date: 20141205
> Your constants_pdef.py
> All tracks and data available
>
> Results - there are two storms that meet the criteria for 00 and 06
UTC
> initializations and only the one for 12 and 18 UTC inits:
>
> In extract_tiles%
> 20141205_00:
> filter_20141205_00.tcst ML1200152014 ML1200282014
> 20141205_06:
> filter_20141205_06.tcst ML1200152014 ML1200282014
> 20141205_12:
> filter_20141205_12.tcst ML1200152014
> 20141205_18:
> filter_20141205_18.tcst ML1200152014
>
> In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6
files
> found
> that match the date and lead time criteria (20141205 F000) - 4 for
> ML1200152014 and 2 for ML1200282014:
>
> -
> series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_1800_000.nc
> -
> series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_0600_000.nc
> -
> series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_
> F000_gfs_4_20141205_0600_000.nc
> -
> series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_0000_000.nc
> -
> series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_
> F000_gfs_4_20141205_0000_000.nc
> -
> series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_
> F000_gfs_4_20141205_1200_000.nc
>
> In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
> the series_cnt_TOTAL is listed at 6
> the lats/lons appear to provide a 30 deg by 30 deg box
>
> lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5,
29,
> 29.5,
> 30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5, 36,
36.5,
> 37,
> 37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43,
43.5, 44,
> 44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50,
50.5, 51,
> 51.5, 52, 52.5 ;
>
> lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5, -111,
> -110.5,
> -110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
> -105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
> -100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5,
-95,
> -94.5,
> -94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5, -89,
-88.5,
> -88, -87.5, -87, -86.5, -86, -85.5 ;
>
> So, it appears that portion of the system is working in an expected
way,
> however it does not appear to allow the user to precisely focus in
one
> Valid time for debugging purposes. That's something we should add.
>
> When you were doing the single track testing, did you do it in a new
> directory so extract tiles would have to run again and only pull out
the
> pertinent tiles? Can you send me the track file, or tell me which
track it
> is that you tested and still had series_cnt_TOTAL greater than 600+?
I
> really don't know how to debug it any further without without that
info.
>
> Thanks, Tara
>
>
>
> On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu> wrote:
>
> > Xinxia,
> >
> > Minna and I met today and noticed that when there were only 2
storm tiles
> > for series_analysis for a given lead time (on 20141205_00), there
was a
> > listing of 6 in the series_cnt_TOTAL. Minna is looking into this.
> >
> > Sorry for delay. She just returned from time off yesterday and I
> returned
> > today.
> >
> > Cheers, Tara
> >
> > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >>
> >> Hi Tara,
> >>
> >>
> >> Hope you had a wonderful vacation. I found the corresponding
tracks in
> >> MET and I deleted all other tracks information in track_data and
> >> track_data_atcf. And in the track data of MET, I notice the
minimal
> >> pressure is around 960hPa. After I ran the software, it still has
N =
> 600+
> >> cases while it should have only 1. And the minimal pressure is
larger
> than
> >> 960hPa. I don't know where it went wrong.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Xinxia
> >>
> >> ________________________________
> >> From: Tara Jensen via RT <met_help at ucar.edu>
> >> Sent: Thursday, May 25, 2017 2:39:12 PM
> >> To: minnawin at ucar.edu
> >> Cc: Xinxia_Song at outlook.com
> >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> >> days' worth of data based on area
> >>
> >> Xinxia,
> >>
> >> I'm sorry, I can't tell you for sure right now. Technically I'm
> answering
> >> you while I'm on vacation and right now I'm away from my
computer. I
> will
> >> try to look at the file tonight.
> >>
> >> In the meantime, I would suggest you focus your attention on
lines with
> ML
> >> in the basin column. If you don't know which that is, please
refer to
> the
> >> ATCF documentation I pointed you to earlier. I would cut the
file down
> to
> >> one line that looks like its over US possibly and run it through
the
> >> system
> >> and see where the extracted tile netcdf is located.
> >>
> >> Cheers, Tara
> >>
> >>
> >> On May 25, 2017 1:24 PM, "Xinxia Song via RT" <met_help at ucar.edu>
> wrote:
> >>
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >>
> >> Hi Tara,
> >>
> >>
> >> Right now I understand amlq is forecast and bmlq is observation.
When I
> >> open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> >>
> >> I guess it means 20141205 initiate at time step 00. Then I notice
> there're
> >> tow columns: 479S, 1332W. I guess they are latitude and
longitude. they
> >> are
> >> not usual expression. Could you tell me what's the usual
expression for
> >> 479S and 1322W?
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Xinxia
> >>
> >> ________________________________
> >> From: Tara Jensen via RT <met_help at ucar.edu>
> >> Sent: Thursday, May 25, 2017 10:56:17 AM
> >> To: minnawin at ucar.edu
> >> Cc: Xinxia_Song at outlook.com
> >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> >> days' worth of data based on area
> >>
> >> Xinxia,
> >>
> >> Sorry we did not make this explicitly clear in the README. The
data in
> >> *track_data* are the original files from EMC. They are in a
modified
> ATCF
> >> file format and won't work with MET or with whatever scripts
Minna
> helped
> >> you with. The data in *track_data_atcf* is the result of a
reprocessing
> >> script to put the data into ATCF file format that is used by the
> National
> >> Hurricane Center and is what MET reads. You should modify a file
in
> >> track_data_atcf.
> >>
> >> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> of
> >> naming convention and file format. Basically, files beginning
with "a"
> >> are
> >> forecast tracks and beginning with "b" are called "best tracks"
or in
> >> other
> >> words the analysis/"observed" track.
> >>
> >> Hope this helps get you going in the right direction again.
> >> Cheers, Tara
> >>
> >>
> >> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT
<met_help at ucar.edu
> >
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >> >
> >> > Hi Tara,
> >> >
> >> >
> >> > I just a little confused with the track information. First, it
has two
> >> > folders, one is track_data and another is track_data_atcf.
Should I
> edit
> >> > both or just one? Then within the track_data folder, it has
amlq* and
> >> bmlq*
> >> > files. which file should I edit And the end is from 0001 to
0280, what
> >> does
> >> > this mean? And when I open the file, it has many columns, could
you
> help
> >> me
> >> > to find out the critical columns like timestep, lat, lon and
cyclone
> id?
> >> >
> >> > Below is the first line of amlq2014123118.gfso.0005:
> >> >
> >> >
> >> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03, GFSO,
000,
> >> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> >> 178,
> >> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39, 0088
> >> >
> >> >
> >> > Thanks,
> >> >
> >> >
> >> > Xinxia
> >> >
> >> > ________________________________
> >> > From: Tara Jensen via RT <met_help at ucar.edu>
> >> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> >> > To: minnawin at ucar.edu
> >> > Cc: Xinxia_Song at outlook.com
> >> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> >> > days' worth of data based on area
> >> >
> >> > Hi Xinxia,
> >> >
> >> > Tara here. Minna is out until next week, as am I, and much of
our
> >> met_help
> >> > staff. We will look into this further next Wed or Thur.
> >> >
> >> > I have not had time to run through the example you and Minna
are
> working
> >> on
> >> > so really don't understand how you have it set-up for
debugging. If
> you
> >> > haven't done so yet, I'd suggest running just 1 extra tropical
cyclone
> >> > track through your system (assuming this is what you refer to
as the
> >> > Fortran code) and through MET+. You could do so by deleting
all
> tracks
> >> > except one from the input track files (making sure it's the
same
> track).
> >> I
> >> > would suggest using your plotting package to plot both the
netcdf
> output
> >> of
> >> > the Fortran code and MET+.
> >> >
> >> > If there's a difference between the fields extracted, then we
have a
> >> good
> >> > place to start. If there isn't a difference, then add another
track
> in,
> >> > run the two systems, compare etc...
> >> >
> >> > Cheers, Tara
> >> >
> >> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> met_help at ucar.edu>
> >> > wrote:
> >> >
> >> > >
> >> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> >> > >
> >> > > Hi Minna,
> >> > >
> >> > >
> >> > > I think the MET doesn't exclude the points fall outside the
boundary
> >> > cause
> >> > > we have more cyclones tracked in MET than in Fortran code. Is
there
> >> any
> >> > > possibility we exclude them successfully? Otherwise we need
to
> modify
> >> the
> >> > > track file for Fortran code and Fortran code itself.
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > >
> >> > > Xinxia
> >> > >
> >> > > ________________________________
> >> > > From: Minna Win via RT <met_help at ucar.edu>
> >> > > Sent: Monday, May 22, 2017 6:45:16 PM
> >> > > Cc: Xinxia_Song at outlook.com
> >> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> >> one
> >> > > days' worth of data based on area
> >> > >
> >> > > Hi Xinxia,
> >> > >
> >> > > From what I've found thus far, it looks like the masking by
region
> is
> >> > > working as expected (this uses the MET tool TC-Stat). In
some
> cases,
> >> > there
> >> > > is a point (or points) that lie outside the boundary because
they
> >> belong
> >> > to
> >> > > a storm track which has an init time (with lead hour =0)
within the
> >> > > boundary (this is consistent with the -out_init_mask argument
used
> to
> >> do
> >> > > the masking). The METplus code does not perform any
"surgical"
> >> removal
> >> > of
> >> > > these few outliers. We get even more outliers when we
perform
> >> regridding
> >> > > with the MET tool regrid_data_plane. This uses the atrack and
btrack
> >> > > lon,lat values and interpolates points using the nearest
neighbor
> >> > > technique. We are requesting 60 lons and 60 lats total for
the
> >> regridded
> >> > > tiles, so if we have a few outliers, by the time we finish
> regridding
> >> we
> >> > > end up with even more points that are outside the boundary.
> >> > >
> >> > > Is this what you were referring to when you thought the
region
> wasn't
> >> > > getting masked? I used the values in your constants_pdef.py
file
> and
> >> > they
> >> > > look OK.
> >> > >
> >> > > Thanks,
> >> > > Minna
> >> > >
> >> > > ---------------
> >> > > Minna Win
> >> > > NCAR
> >> > > Research Applications Lab
> >> > > Phone: 303-497-8423
> >> > > Fax: 302-497-8401
> >> > >
> >> > >
> >> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> Xinxia_Song at outlook.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Hi Minna,
> >> > > >
> >> > > > I use the constants_pdef.py to shrink the MET region the
the one
> >> that
> >> > > > Fortran code uses. But seems it doesn't do it correctly.
Could you
> >> help
> >> > > to
> >> > > > check the constants_pdef.py to see where is the problem?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Xinxia
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> > Tara Jensen
> >> > Project Manager II
> >> > NCAR RAL and DTC
> >> > PO Box 3000, Boulder, Colorado 80307 USA
> >> > +1 303-497-8479 jensen at ucar.edu
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Tara Jensen
> >> Project Manager II
> >> NCAR RAL and DTC
> >> PO Box 3000, Boulder, Colorado 80307 USA
> >> +1 303-497-8479 jensen at ucar.edu
> >>
> >>
> >>
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
> >
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Fri Jun 02 18:18:05 2017
Xinxia,
Thanks for clarifying. I'll continue to work on setting up test with
that
track.
Cheers, Tara
On Fri, Jun 2, 2017 at 6:15 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> The region is 25N-65N, 260E-320E
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 8:13:13 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I agree testing with one day is a good place to start, then add
another and
> another until we are confident it is working properly. I'm working
on
> setting up a test with your 1 track and am honestly surprised to see
that
> MET+ is retaining the track. Storm 0028 appears to be at 60N and
higher
> and thus is outside your region - which according to the netcdf file
is 23N
> to 53N. Is this the correct region of interest?
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 5:56 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > The 600+ results are because I ran the MET before with 2 months
and the
> > output is kept. When I run a single day, it doesn't overwrite the
output
> > but keeps them so it has 600+ cases counted.
> >
> >
> > Right now I think to compare the MET and Fortran, we could only
compare a
> > single day's composite.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Friday, June 2, 2017 3:05:00 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > I'm doing some additional testing.
> >
> > Date: 20141205
> > Your constants_pdef.py
> > All tracks and data available
> >
> > Results - there are two storms that meet the criteria for 00 and
06 UTC
> > initializations and only the one for 12 and 18 UTC inits:
> >
> > In extract_tiles%
> > 20141205_00:
> > filter_20141205_00.tcst ML1200152014 ML1200282014
> > 20141205_06:
> > filter_20141205_06.tcst ML1200152014 ML1200282014
> > 20141205_12:
> > filter_20141205_12.tcst ML1200152014
> > 20141205_18:
> > filter_20141205_18.tcst ML1200152014
> >
> > In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6
files
> > found
> > that match the date and lead time criteria (20141205 F000) - 4 for
> > ML1200152014 and 2 for ML1200282014:
> >
> > -
> > series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_1800_000.nc
> > -
> > series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_0600_000.nc
> > -
> > series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_
> > F000_gfs_4_20141205_0600_000.nc
> > -
> > series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_0000_000.nc
> > -
> > series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_
> > F000_gfs_4_20141205_0000_000.nc
> > -
> > series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_1200_000.nc
> >
> > In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
> > the series_cnt_TOTAL is listed at 6
> > the lats/lons appear to provide a 30 deg by 30 deg box
> >
> > lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5,
29,
> > 29.5,
> > 30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5,
36, 36.5,
> > 37,
> > 37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43,
43.5, 44,
> > 44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50,
50.5, 51,
> > 51.5, 52, 52.5 ;
> >
> > lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5,
-111,
> > -110.5,
> > -110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
> > -105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
> > -100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5,
-95,
> > -94.5,
> > -94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5,
-89,
> -88.5,
> > -88, -87.5, -87, -86.5, -86, -85.5 ;
> >
> > So, it appears that portion of the system is working in an
expected way,
> > however it does not appear to allow the user to precisely focus in
one
> > Valid time for debugging purposes. That's something we should add.
> >
> > When you were doing the single track testing, did you do it in a
new
> > directory so extract tiles would have to run again and only pull
out the
> > pertinent tiles? Can you send me the track file, or tell me which
track
> it
> > is that you tested and still had series_cnt_TOTAL greater than
600+? I
> > really don't know how to debug it any further without without that
info.
> >
> > Thanks, Tara
> >
> >
> >
> > On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu>
wrote:
> >
> > > Xinxia,
> > >
> > > Minna and I met today and noticed that when there were only 2
storm
> tiles
> > > for series_analysis for a given lead time (on 20141205_00),
there was a
> > > listing of 6 in the series_cnt_TOTAL. Minna is looking into
this.
> > >
> > > Sorry for delay. She just returned from time off yesterday and
I
> > returned
> > > today.
> > >
> > > Cheers, Tara
> > >
> > > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >>
> > >> Hi Tara,
> > >>
> > >>
> > >> Hope you had a wonderful vacation. I found the corresponding
tracks in
> > >> MET and I deleted all other tracks information in track_data
and
> > >> track_data_atcf. And in the track data of MET, I notice the
minimal
> > >> pressure is around 960hPa. After I ran the software, it still
has N =
> > 600+
> > >> cases while it should have only 1. And the minimal pressure is
larger
> > than
> > >> 960hPa. I don't know where it went wrong.
> > >>
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Xinxia
> > >>
> > >> ________________________________
> > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > >> Sent: Thursday, May 25, 2017 2:39:12 PM
> > >> To: minnawin at ucar.edu
> > >> Cc: Xinxia_Song at outlook.com
> > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > >> days' worth of data based on area
> > >>
> > >> Xinxia,
> > >>
> > >> I'm sorry, I can't tell you for sure right now. Technically I'm
> > answering
> > >> you while I'm on vacation and right now I'm away from my
computer. I
> > will
> > >> try to look at the file tonight.
> > >>
> > >> In the meantime, I would suggest you focus your attention on
lines
> with
> > ML
> > >> in the basin column. If you don't know which that is, please
refer to
> > the
> > >> ATCF documentation I pointed you to earlier. I would cut the
file
> down
> > to
> > >> one line that looks like its over US possibly and run it
through the
> > >> system
> > >> and see where the extracted tile netcdf is located.
> > >>
> > >> Cheers, Tara
> > >>
> > >>
> > >> On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> > wrote:
> > >>
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >>
> > >> Hi Tara,
> > >>
> > >>
> > >> Right now I understand amlq is forecast and bmlq is
observation. When
> I
> > >> open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > >>
> > >> I guess it means 20141205 initiate at time step 00. Then I
notice
> > there're
> > >> tow columns: 479S, 1332W. I guess they are latitude and
longitude.
> they
> > >> are
> > >> not usual expression. Could you tell me what's the usual
expression
> for
> > >> 479S and 1322W?
> > >>
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Xinxia
> > >>
> > >> ________________________________
> > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > >> Sent: Thursday, May 25, 2017 10:56:17 AM
> > >> To: minnawin at ucar.edu
> > >> Cc: Xinxia_Song at outlook.com
> > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > >> days' worth of data based on area
> > >>
> > >> Xinxia,
> > >>
> > >> Sorry we did not make this explicitly clear in the README. The
data
> in
> > >> *track_data* are the original files from EMC. They are in a
modified
> > ATCF
> > >> file format and won't work with MET or with whatever scripts
Minna
> > helped
> > >> you with. The data in *track_data_atcf* is the result of a
> reprocessing
> > >> script to put the data into ATCF file format that is used by
the
> > National
> > >> Hurricane Center and is what MET reads. You should modify a
file in
> > >> track_data_atcf.
> > >>
> > >> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> > of
> > >> naming convention and file format. Basically, files beginning
with
> "a"
> > >> are
> > >> forecast tracks and beginning with "b" are called "best tracks"
or in
> > >> other
> > >> words the analysis/"observed" track.
> > >>
> > >> Hope this helps get you going in the right direction again.
> > >> Cheers, Tara
> > >>
> > >>
> > >> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> met_help at ucar.edu
> > >
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > >> >
> > >> > Hi Tara,
> > >> >
> > >> >
> > >> > I just a little confused with the track information. First,
it has
> two
> > >> > folders, one is track_data and another is track_data_atcf.
Should I
> > edit
> > >> > both or just one? Then within the track_data folder, it has
amlq*
> and
> > >> bmlq*
> > >> > files. which file should I edit And the end is from 0001 to
0280,
> what
> > >> does
> > >> > this mean? And when I open the file, it has many columns,
could you
> > help
> > >> me
> > >> > to find out the critical columns like timestep, lat, lon and
cyclone
> > id?
> > >> >
> > >> > Below is the first line of amlq2014123118.gfso.0005:
> > >> >
> > >> >
> > >> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO,
> 000,
> > >> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> > >> 178,
> > >> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39,
0088
> > >> >
> > >> >
> > >> > Thanks,
> > >> >
> > >> >
> > >> > Xinxia
> > >> >
> > >> > ________________________________
> > >> > From: Tara Jensen via RT <met_help at ucar.edu>
> > >> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > >> > To: minnawin at ucar.edu
> > >> > Cc: Xinxia_Song at outlook.com
> > >> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > >> > days' worth of data based on area
> > >> >
> > >> > Hi Xinxia,
> > >> >
> > >> > Tara here. Minna is out until next week, as am I, and much
of our
> > >> met_help
> > >> > staff. We will look into this further next Wed or Thur.
> > >> >
> > >> > I have not had time to run through the example you and Minna
are
> > working
> > >> on
> > >> > so really don't understand how you have it set-up for
debugging. If
> > you
> > >> > haven't done so yet, I'd suggest running just 1 extra
tropical
> cyclone
> > >> > track through your system (assuming this is what you refer to
as the
> > >> > Fortran code) and through MET+. You could do so by deleting
all
> > tracks
> > >> > except one from the input track files (making sure it's the
same
> > track).
> > >> I
> > >> > would suggest using your plotting package to plot both the
netcdf
> > output
> > >> of
> > >> > the Fortran code and MET+.
> > >> >
> > >> > If there's a difference between the fields extracted, then we
have a
> > >> good
> > >> > place to start. If there isn't a difference, then add
another track
> > in,
> > >> > run the two systems, compare etc...
> > >> >
> > >> > Cheers, Tara
> > >> >
> > >> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> > met_help at ucar.edu>
> > >> > wrote:
> > >> >
> > >> > >
> > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >> > >
> > >> > > Hi Minna,
> > >> > >
> > >> > >
> > >> > > I think the MET doesn't exclude the points fall outside the
> boundary
> > >> > cause
> > >> > > we have more cyclones tracked in MET than in Fortran code.
Is
> there
> > >> any
> > >> > > possibility we exclude them successfully? Otherwise we need
to
> > modify
> > >> the
> > >> > > track file for Fortran code and Fortran code itself.
> > >> > >
> > >> > >
> > >> > > Thanks,
> > >> > >
> > >> > >
> > >> > > Xinxia
> > >> > >
> > >> > > ________________________________
> > >> > > From: Minna Win via RT <met_help at ucar.edu>
> > >> > > Sent: Monday, May 22, 2017 6:45:16 PM
> > >> > > Cc: Xinxia_Song at outlook.com
> > >> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply:
> METplus-filtering
> > >> one
> > >> > > days' worth of data based on area
> > >> > >
> > >> > > Hi Xinxia,
> > >> > >
> > >> > > From what I've found thus far, it looks like the masking by
region
> > is
> > >> > > working as expected (this uses the MET tool TC-Stat). In
some
> > cases,
> > >> > there
> > >> > > is a point (or points) that lie outside the boundary
because they
> > >> belong
> > >> > to
> > >> > > a storm track which has an init time (with lead hour =0)
within
> the
> > >> > > boundary (this is consistent with the -out_init_mask
argument used
> > to
> > >> do
> > >> > > the masking). The METplus code does not perform any
"surgical"
> > >> removal
> > >> > of
> > >> > > these few outliers. We get even more outliers when we
perform
> > >> regridding
> > >> > > with the MET tool regrid_data_plane. This uses the atrack
and
> btrack
> > >> > > lon,lat values and interpolates points using the nearest
neighbor
> > >> > > technique. We are requesting 60 lons and 60 lats total for
the
> > >> regridded
> > >> > > tiles, so if we have a few outliers, by the time we finish
> > regridding
> > >> we
> > >> > > end up with even more points that are outside the boundary.
> > >> > >
> > >> > > Is this what you were referring to when you thought the
region
> > wasn't
> > >> > > getting masked? I used the values in your
constants_pdef.py file
> > and
> > >> > they
> > >> > > look OK.
> > >> > >
> > >> > > Thanks,
> > >> > > Minna
> > >> > >
> > >> > > ---------------
> > >> > > Minna Win
> > >> > > NCAR
> > >> > > Research Applications Lab
> > >> > > Phone: 303-497-8423
> > >> > > Fax: 302-497-8401
> > >> > >
> > >> > >
> > >> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > Xinxia_Song at outlook.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > Hi Minna,
> > >> > > >
> > >> > > > I use the constants_pdef.py to shrink the MET region the
the one
> > >> that
> > >> > > > Fortran code uses. But seems it doesn't do it correctly.
Could
> you
> > >> help
> > >> > > to
> > >> > > > check the constants_pdef.py to see where is the problem?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Xinxia
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> > Tara Jensen
> > >> > Project Manager II
> > >> > NCAR RAL and DTC
> > >> > PO Box 3000, Boulder, Colorado 80307 USA
> > >> > +1 303-497-8479 jensen at ucar.edu
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> Tara Jensen
> > >> Project Manager II
> > >> NCAR RAL and DTC
> > >> PO Box 3000, Boulder, Colorado 80307 USA
> > >> +1 303-497-8479 jensen at ucar.edu
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
> > >
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Xinxia Song
Time: Sat Jun 03 08:13:25 2017
Hi Tara and Prof. Colle,
I compared the MET with Fortran code in a single day's composite and I
think they are similar. The structure of the cyclones may be a little
different because two systems are different. But the cyclone center
pressures are very similar.
Attached is the MET and Fortran results
Thanks,
Xinxia
________________________________
From: Tara Jensen via RT <met_help at ucar.edu>
Sent: Friday, June 2, 2017 8:18:05 PM
To: minnawin at ucar.edu
Cc: Xinxia_Song at outlook.com
Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering one
days' worth of data based on area
Xinxia,
Thanks for clarifying. I'll continue to work on setting up test with
that
track.
Cheers, Tara
On Fri, Jun 2, 2017 at 6:15 PM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara,
>
>
> The region is 25N-65N, 260E-320E
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 8:13:13 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> I agree testing with one day is a good place to start, then add
another and
> another until we are confident it is working properly. I'm working
on
> setting up a test with your 1 track and am honestly surprised to see
that
> MET+ is retaining the track. Storm 0028 appears to be at 60N and
higher
> and thus is outside your region - which according to the netcdf file
is 23N
> to 53N. Is this the correct region of interest?
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 5:56 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > The 600+ results are because I ran the MET before with 2 months
and the
> > output is kept. When I run a single day, it doesn't overwrite the
output
> > but keeps them so it has 600+ cases counted.
> >
> >
> > Right now I think to compare the MET and Fortran, we could only
compare a
> > single day's composite.
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Friday, June 2, 2017 3:05:00 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > I'm doing some additional testing.
> >
> > Date: 20141205
> > Your constants_pdef.py
> > All tracks and data available
> >
> > Results - there are two storms that meet the criteria for 00 and
06 UTC
> > initializations and only the one for 12 and 18 UTC inits:
> >
> > In extract_tiles%
> > 20141205_00:
> > filter_20141205_00.tcst ML1200152014 ML1200282014
> > 20141205_06:
> > filter_20141205_06.tcst ML1200152014 ML1200282014
> > 20141205_12:
> > filter_20141205_12.tcst ML1200152014
> > 20141205_18:
> > filter_20141205_18.tcst ML1200152014
> >
> > In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6
files
> > found
> > that match the date and lead time criteria (20141205 F000) - 4 for
> > ML1200152014 and 2 for ML1200282014:
> >
> > -
> > series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_1800_000.nc
> > -
> > series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_0600_000.nc
> > -
> > series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_
> > F000_gfs_4_20141205_0600_000.nc
> > -
> > series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_0000_000.nc
> > -
> > series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_
> > F000_gfs_4_20141205_0000_000.nc
> > -
> > series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_
> > F000_gfs_4_20141205_1200_000.nc
> >
> > In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
> > the series_cnt_TOTAL is listed at 6
> > the lats/lons appear to provide a 30 deg by 30 deg box
> >
> > lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28, 28.5,
29,
> > 29.5,
> > 30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5,
36, 36.5,
> > 37,
> > 37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43,
43.5, 44,
> > 44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50,
50.5, 51,
> > 51.5, 52, 52.5 ;
> >
> > lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5,
-111,
> > -110.5,
> > -110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5, -106,
-105.5,
> > -105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5, -101,
-100.5,
> > -100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5,
-95,
> > -94.5,
> > -94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5,
-89,
> -88.5,
> > -88, -87.5, -87, -86.5, -86, -85.5 ;
> >
> > So, it appears that portion of the system is working in an
expected way,
> > however it does not appear to allow the user to precisely focus in
one
> > Valid time for debugging purposes. That's something we should add.
> >
> > When you were doing the single track testing, did you do it in a
new
> > directory so extract tiles would have to run again and only pull
out the
> > pertinent tiles? Can you send me the track file, or tell me which
track
> it
> > is that you tested and still had series_cnt_TOTAL greater than
600+? I
> > really don't know how to debug it any further without without that
info.
> >
> > Thanks, Tara
> >
> >
> >
> > On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu>
wrote:
> >
> > > Xinxia,
> > >
> > > Minna and I met today and noticed that when there were only 2
storm
> tiles
> > > for series_analysis for a given lead time (on 20141205_00),
there was a
> > > listing of 6 in the series_cnt_TOTAL. Minna is looking into
this.
> > >
> > > Sorry for delay. She just returned from time off yesterday and
I
> > returned
> > > today.
> > >
> > > Cheers, Tara
> > >
> > > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >>
> > >> Hi Tara,
> > >>
> > >>
> > >> Hope you had a wonderful vacation. I found the corresponding
tracks in
> > >> MET and I deleted all other tracks information in track_data
and
> > >> track_data_atcf. And in the track data of MET, I notice the
minimal
> > >> pressure is around 960hPa. After I ran the software, it still
has N =
> > 600+
> > >> cases while it should have only 1. And the minimal pressure is
larger
> > than
> > >> 960hPa. I don't know where it went wrong.
> > >>
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Xinxia
> > >>
> > >> ________________________________
> > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > >> Sent: Thursday, May 25, 2017 2:39:12 PM
> > >> To: minnawin at ucar.edu
> > >> Cc: Xinxia_Song at outlook.com
> > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > >> days' worth of data based on area
> > >>
> > >> Xinxia,
> > >>
> > >> I'm sorry, I can't tell you for sure right now. Technically I'm
> > answering
> > >> you while I'm on vacation and right now I'm away from my
computer. I
> > will
> > >> try to look at the file tonight.
> > >>
> > >> In the meantime, I would suggest you focus your attention on
lines
> with
> > ML
> > >> in the basin column. If you don't know which that is, please
refer to
> > the
> > >> ATCF documentation I pointed you to earlier. I would cut the
file
> down
> > to
> > >> one line that looks like its over US possibly and run it
through the
> > >> system
> > >> and see where the extracted tile netcdf is located.
> > >>
> > >> Cheers, Tara
> > >>
> > >>
> > >> On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> > wrote:
> > >>
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >>
> > >> Hi Tara,
> > >>
> > >>
> > >> Right now I understand amlq is forecast and bmlq is
observation. When
> I
> > >> open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > >>
> > >> I guess it means 20141205 initiate at time step 00. Then I
notice
> > there're
> > >> tow columns: 479S, 1332W. I guess they are latitude and
longitude.
> they
> > >> are
> > >> not usual expression. Could you tell me what's the usual
expression
> for
> > >> 479S and 1322W?
> > >>
> > >>
> > >> Thanks,
> > >>
> > >>
> > >> Xinxia
> > >>
> > >> ________________________________
> > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > >> Sent: Thursday, May 25, 2017 10:56:17 AM
> > >> To: minnawin at ucar.edu
> > >> Cc: Xinxia_Song at outlook.com
> > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> one
> > >> days' worth of data based on area
> > >>
> > >> Xinxia,
> > >>
> > >> Sorry we did not make this explicitly clear in the README. The
data
> in
> > >> *track_data* are the original files from EMC. They are in a
modified
> > ATCF
> > >> file format and won't work with MET or with whatever scripts
Minna
> > helped
> > >> you with. The data in *track_data_atcf* is the result of a
> reprocessing
> > >> script to put the data into ATCF file format that is used by
the
> > National
> > >> Hurricane Center and is what MET reads. You should modify a
file in
> > >> track_data_atcf.
> > >>
> > >> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
description
> > of
> > >> naming convention and file format. Basically, files beginning
with
> "a"
> > >> are
> > >> forecast tracks and beginning with "b" are called "best tracks"
or in
> > >> other
> > >> words the analysis/"observed" track.
> > >>
> > >> Hope this helps get you going in the right direction again.
> > >> Cheers, Tara
> > >>
> > >>
> > >> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> met_help at ucar.edu
> > >
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > >> >
> > >> > Hi Tara,
> > >> >
> > >> >
> > >> > I just a little confused with the track information. First,
it has
> two
> > >> > folders, one is track_data and another is track_data_atcf.
Should I
> > edit
> > >> > both or just one? Then within the track_data folder, it has
amlq*
> and
> > >> bmlq*
> > >> > files. which file should I edit And the end is from 0001 to
0280,
> what
> > >> does
> > >> > this mean? And when I open the file, it has many columns,
could you
> > help
> > >> me
> > >> > to find out the critical columns like timestep, lat, lon and
cyclone
> > id?
> > >> >
> > >> > Below is the first line of amlq2014123118.gfso.0005:
> > >> >
> > >> >
> > >> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO,
> 000,
> > >> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000, 0000,
1011,
> > >> 178,
> > >> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39,
0088
> > >> >
> > >> >
> > >> > Thanks,
> > >> >
> > >> >
> > >> > Xinxia
> > >> >
> > >> > ________________________________
> > >> > From: Tara Jensen via RT <met_help at ucar.edu>
> > >> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > >> > To: minnawin at ucar.edu
> > >> > Cc: Xinxia_Song at outlook.com
> > >> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > >> > days' worth of data based on area
> > >> >
> > >> > Hi Xinxia,
> > >> >
> > >> > Tara here. Minna is out until next week, as am I, and much
of our
> > >> met_help
> > >> > staff. We will look into this further next Wed or Thur.
> > >> >
> > >> > I have not had time to run through the example you and Minna
are
> > working
> > >> on
> > >> > so really don't understand how you have it set-up for
debugging. If
> > you
> > >> > haven't done so yet, I'd suggest running just 1 extra
tropical
> cyclone
> > >> > track through your system (assuming this is what you refer to
as the
> > >> > Fortran code) and through MET+. You could do so by deleting
all
> > tracks
> > >> > except one from the input track files (making sure it's the
same
> > track).
> > >> I
> > >> > would suggest using your plotting package to plot both the
netcdf
> > output
> > >> of
> > >> > the Fortran code and MET+.
> > >> >
> > >> > If there's a difference between the fields extracted, then we
have a
> > >> good
> > >> > place to start. If there isn't a difference, then add
another track
> > in,
> > >> > run the two systems, compare etc...
> > >> >
> > >> > Cheers, Tara
> > >> >
> > >> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> > met_help at ucar.edu>
> > >> > wrote:
> > >> >
> > >> > >
> > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >> > >
> > >> > > Hi Minna,
> > >> > >
> > >> > >
> > >> > > I think the MET doesn't exclude the points fall outside the
> boundary
> > >> > cause
> > >> > > we have more cyclones tracked in MET than in Fortran code.
Is
> there
> > >> any
> > >> > > possibility we exclude them successfully? Otherwise we need
to
> > modify
> > >> the
> > >> > > track file for Fortran code and Fortran code itself.
> > >> > >
> > >> > >
> > >> > > Thanks,
> > >> > >
> > >> > >
> > >> > > Xinxia
> > >> > >
> > >> > > ________________________________
> > >> > > From: Minna Win via RT <met_help at ucar.edu>
> > >> > > Sent: Monday, May 22, 2017 6:45:16 PM
> > >> > > Cc: Xinxia_Song at outlook.com
> > >> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply:
> METplus-filtering
> > >> one
> > >> > > days' worth of data based on area
> > >> > >
> > >> > > Hi Xinxia,
> > >> > >
> > >> > > From what I've found thus far, it looks like the masking by
region
> > is
> > >> > > working as expected (this uses the MET tool TC-Stat). In
some
> > cases,
> > >> > there
> > >> > > is a point (or points) that lie outside the boundary
because they
> > >> belong
> > >> > to
> > >> > > a storm track which has an init time (with lead hour =0)
within
> the
> > >> > > boundary (this is consistent with the -out_init_mask
argument used
> > to
> > >> do
> > >> > > the masking). The METplus code does not perform any
"surgical"
> > >> removal
> > >> > of
> > >> > > these few outliers. We get even more outliers when we
perform
> > >> regridding
> > >> > > with the MET tool regrid_data_plane. This uses the atrack
and
> btrack
> > >> > > lon,lat values and interpolates points using the nearest
neighbor
> > >> > > technique. We are requesting 60 lons and 60 lats total for
the
> > >> regridded
> > >> > > tiles, so if we have a few outliers, by the time we finish
> > regridding
> > >> we
> > >> > > end up with even more points that are outside the boundary.
> > >> > >
> > >> > > Is this what you were referring to when you thought the
region
> > wasn't
> > >> > > getting masked? I used the values in your
constants_pdef.py file
> > and
> > >> > they
> > >> > > look OK.
> > >> > >
> > >> > > Thanks,
> > >> > > Minna
> > >> > >
> > >> > > ---------------
> > >> > > Minna Win
> > >> > > NCAR
> > >> > > Research Applications Lab
> > >> > > Phone: 303-497-8423
> > >> > > Fax: 302-497-8401
> > >> > >
> > >> > >
> > >> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > Xinxia_Song at outlook.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > Hi Minna,
> > >> > > >
> > >> > > > I use the constants_pdef.py to shrink the MET region the
the one
> > >> that
> > >> > > > Fortran code uses. But seems it doesn't do it correctly.
Could
> you
> > >> help
> > >> > > to
> > >> > > > check the constants_pdef.py to see where is the problem?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Xinxia
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> > Tara Jensen
> > >> > Project Manager II
> > >> > NCAR RAL and DTC
> > >> > PO Box 3000, Boulder, Colorado 80307 USA
> > >> > +1 303-497-8479 jensen at ucar.edu
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> Tara Jensen
> > >> Project Manager II
> > >> NCAR RAL and DTC
> > >> PO Box 3000, Boulder, Colorado 80307 USA
> > >> +1 303-497-8479 jensen at ucar.edu
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
> > >
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
Subject: METplus-filtering one days' worth of data based on area
From: Tara Jensen
Time: Mon Jun 05 12:13:01 2017
Thanks for the update Xinxia. I'm going to close this ticket now.
Send a
new request for help to met_help when the need arises.
Cheers, Tara
On Sat, Jun 3, 2017 at 8:13 AM, Xinxia Song via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
>
> Hi Tara and Prof. Colle,
>
>
> I compared the MET with Fortran code in a single day's composite and
I
> think they are similar. The structure of the cyclones may be a
little
> different because two systems are different. But the cyclone center
> pressures are very similar.
>
>
> Attached is the MET and Fortran results
>
>
> Thanks,
>
>
> Xinxia
>
> ________________________________
> From: Tara Jensen via RT <met_help at ucar.edu>
> Sent: Friday, June 2, 2017 8:18:05 PM
> To: minnawin at ucar.edu
> Cc: Xinxia_Song at outlook.com
> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> days' worth of data based on area
>
> Xinxia,
>
> Thanks for clarifying. I'll continue to work on setting up test
with that
> track.
>
> Cheers, Tara
>
> On Fri, Jun 2, 2017 at 6:15 PM, Xinxia Song via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> >
> > Hi Tara,
> >
> >
> > The region is 25N-65N, 260E-320E
> >
> >
> > Thanks,
> >
> >
> > Xinxia
> >
> > ________________________________
> > From: Tara Jensen via RT <met_help at ucar.edu>
> > Sent: Friday, June 2, 2017 8:13:13 PM
> > To: minnawin at ucar.edu
> > Cc: Xinxia_Song at outlook.com
> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-filtering
one
> > days' worth of data based on area
> >
> > Xinxia,
> >
> > I agree testing with one day is a good place to start, then add
another
> and
> > another until we are confident it is working properly. I'm
working on
> > setting up a test with your 1 track and am honestly surprised to
see that
> > MET+ is retaining the track. Storm 0028 appears to be at 60N and
higher
> > and thus is outside your region - which according to the netcdf
file is
> 23N
> > to 53N. Is this the correct region of interest?
> >
> > Cheers, Tara
> >
> > On Fri, Jun 2, 2017 at 5:56 PM, Xinxia Song via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > >
> > > Hi Tara,
> > >
> > >
> > > The 600+ results are because I ran the MET before with 2 months
and the
> > > output is kept. When I run a single day, it doesn't overwrite
the
> output
> > > but keeps them so it has 600+ cases counted.
> > >
> > >
> > > Right now I think to compare the MET and Fortran, we could only
> compare a
> > > single day's composite.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Xinxia
> > >
> > > ________________________________
> > > From: Tara Jensen via RT <met_help at ucar.edu>
> > > Sent: Friday, June 2, 2017 3:05:00 PM
> > > To: minnawin at ucar.edu
> > > Cc: Xinxia_Song at outlook.com
> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering one
> > > days' worth of data based on area
> > >
> > > Xinxia,
> > >
> > > I'm doing some additional testing.
> > >
> > > Date: 20141205
> > > Your constants_pdef.py
> > > All tracks and data available
> > >
> > > Results - there are two storms that meet the criteria for 00 and
06 UTC
> > > initializations and only the one for 12 and 18 UTC inits:
> > >
> > > In extract_tiles%
> > > 20141205_00:
> > > filter_20141205_00.tcst ML1200152014 ML1200282014
> > > 20141205_06:
> > > filter_20141205_06.tcst ML1200152014 ML1200282014
> > > 20141205_12:
> > > filter_20141205_12.tcst ML1200152014
> > > 20141205_18:
> > > filter_20141205_18.tcst ML1200152014
> > >
> > > In series_analysis_lead/series_F000/FCST_FILES_F000 there are 6
files
> > > found
> > > that match the date and lead time criteria (20141205 F000) - 4
for
> > > ML1200152014 and 2 for ML1200282014:
> > >
> > > -
> > > series_lead_filtered/20141205_18/ML1200152014/FCST_TILE_
> > > F000_gfs_4_20141205_1800_000.nc
> > > -
> > > series_lead_filtered/20141205_06/ML1200152014/FCST_TILE_
> > > F000_gfs_4_20141205_0600_000.nc
> > > -
> > > series_lead_filtered/20141205_06/ML1200282014/FCST_TILE_
> > > F000_gfs_4_20141205_0600_000.nc
> > > -
> > > series_lead_filtered/20141205_00/ML1200152014/FCST_TILE_
> > > F000_gfs_4_20141205_0000_000.nc
> > > -
> > > series_lead_filtered/20141205_00/ML1200282014/FCST_TILE_
> > > F000_gfs_4_20141205_0000_000.nc
> > > -
> > > series_lead_filtered/20141205_12/ML1200152014/FCST_TILE_
> > > F000_gfs_4_20141205_1200_000.nc
> > >
> > > In series_analysis_lead/series_F000/series_F000_PRMSL_Z0.nc
> > > the series_cnt_TOTAL is listed at 6
> > > the lats/lons appear to provide a 30 deg by 30 deg box
> > >
> > > lat = 23, 23.5, 24, 24.5, 25, 25.5, 26, 26.5, 27, 27.5, 28,
28.5, 29,
> > > 29.5,
> > > 30, 30.5, 31, 31.5, 32, 32.5, 33, 33.5, 34, 34.5, 35, 35.5,
36,
> 36.5,
> > > 37,
> > > 37.5, 38, 38.5, 39, 39.5, 40, 40.5, 41, 41.5, 42, 42.5, 43,
43.5,
> 44,
> > > 44.5, 45, 45.5, 46, 46.5, 47, 47.5, 48, 48.5, 49, 49.5, 50,
50.5,
> 51,
> > > 51.5, 52, 52.5 ;
> > >
> > > lon = -115, -114.5, -114, -113.5, -113, -112.5, -112, -111.5,
-111,
> > > -110.5,
> > > -110, -109.5, -109, -108.5, -108, -107.5, -107, -106.5,
-106,
> -105.5,
> > > -105, -104.5, -104, -103.5, -103, -102.5, -102, -101.5,
-101,
> -100.5,
> > > -100, -99.5, -99, -98.5, -98, -97.5, -97, -96.5, -96, -95.5,
-95,
> > > -94.5,
> > > -94, -93.5, -93, -92.5, -92, -91.5, -91, -90.5, -90, -89.5,
-89,
> > -88.5,
> > > -88, -87.5, -87, -86.5, -86, -85.5 ;
> > >
> > > So, it appears that portion of the system is working in an
expected
> way,
> > > however it does not appear to allow the user to precisely focus
in one
> > > Valid time for debugging purposes. That's something we should
add.
> > >
> > > When you were doing the single track testing, did you do it in a
new
> > > directory so extract tiles would have to run again and only pull
out
> the
> > > pertinent tiles? Can you send me the track file, or tell me
which track
> > it
> > > is that you tested and still had series_cnt_TOTAL greater than
600+? I
> > > really don't know how to debug it any further without without
that
> info.
> > >
> > > Thanks, Tara
> > >
> > >
> > >
> > > On Thu, Jun 1, 2017 at 4:00 PM, Tara Jensen <jensen at ucar.edu>
wrote:
> > >
> > > > Xinxia,
> > > >
> > > > Minna and I met today and noticed that when there were only 2
storm
> > tiles
> > > > for series_analysis for a given lead time (on 20141205_00),
there
> was a
> > > > listing of 6 in the series_cnt_TOTAL. Minna is looking into
this.
> > > >
> > > > Sorry for delay. She just returned from time off yesterday
and I
> > > returned
> > > > today.
> > > >
> > > > Cheers, Tara
> > > >
> > > > On Tue, May 30, 2017 at 10:00 AM, Xinxia Song via RT <
> > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > >>
> > > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >>
> > > >> Hi Tara,
> > > >>
> > > >>
> > > >> Hope you had a wonderful vacation. I found the corresponding
tracks
> in
> > > >> MET and I deleted all other tracks information in track_data
and
> > > >> track_data_atcf. And in the track data of MET, I notice the
minimal
> > > >> pressure is around 960hPa. After I ran the software, it still
has N
> =
> > > 600+
> > > >> cases while it should have only 1. And the minimal pressure
is
> larger
> > > than
> > > >> 960hPa. I don't know where it went wrong.
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >>
> > > >> Xinxia
> > > >>
> > > >> ________________________________
> > > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > > >> Sent: Thursday, May 25, 2017 2:39:12 PM
> > > >> To: minnawin at ucar.edu
> > > >> Cc: Xinxia_Song at outlook.com
> > > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > > >> days' worth of data based on area
> > > >>
> > > >> Xinxia,
> > > >>
> > > >> I'm sorry, I can't tell you for sure right now. Technically
I'm
> > > answering
> > > >> you while I'm on vacation and right now I'm away from my
computer.
> I
> > > will
> > > >> try to look at the file tonight.
> > > >>
> > > >> In the meantime, I would suggest you focus your attention on
lines
> > with
> > > ML
> > > >> in the basin column. If you don't know which that is, please
refer
> to
> > > the
> > > >> ATCF documentation I pointed you to earlier. I would cut the
file
> > down
> > > to
> > > >> one line that looks like its over US possibly and run it
through the
> > > >> system
> > > >> and see where the extracted tile netcdf is located.
> > > >>
> > > >> Cheers, Tara
> > > >>
> > > >>
> > > >> On May 25, 2017 1:24 PM, "Xinxia Song via RT"
<met_help at ucar.edu>
> > > wrote:
> > > >>
> > > >>
> > > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483
>
> > > >>
> > > >> Hi Tara,
> > > >>
> > > >>
> > > >> Right now I understand amlq is forecast and bmlq is
observation.
> When
> > I
> > > >> open the file, there is one column:
2014120500_F000_479S_1332W_FOF
> > > >>
> > > >> I guess it means 20141205 initiate at time step 00. Then I
notice
> > > there're
> > > >> tow columns: 479S, 1332W. I guess they are latitude and
longitude.
> > they
> > > >> are
> > > >> not usual expression. Could you tell me what's the usual
expression
> > for
> > > >> 479S and 1322W?
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >>
> > > >> Xinxia
> > > >>
> > > >> ________________________________
> > > >> From: Tara Jensen via RT <met_help at ucar.edu>
> > > >> Sent: Thursday, May 25, 2017 10:56:17 AM
> > > >> To: minnawin at ucar.edu
> > > >> Cc: Xinxia_Song at outlook.com
> > > >> Subject: Re: [rt.rap.ucar.edu #80483] AutoReply: METplus-
filtering
> > one
> > > >> days' worth of data based on area
> > > >>
> > > >> Xinxia,
> > > >>
> > > >> Sorry we did not make this explicitly clear in the README.
The data
> > in
> > > >> *track_data* are the original files from EMC. They are in a
modified
> > > ATCF
> > > >> file format and won't work with MET or with whatever scripts
Minna
> > > helped
> > > >> you with. The data in *track_data_atcf* is the result of a
> > reprocessing
> > > >> script to put the data into ATCF file format that is used by
the
> > > National
> > > >> Hurricane Center and is what MET reads. You should modify a
file in
> > > >> track_data_atcf.
> > > >>
> > > >> Please refer to http://ftp.nhc.noaa.gov/atcf/README for a
> description
> > > of
> > > >> naming convention and file format. Basically, files
beginning with
> > "a"
> > > >> are
> > > >> forecast tracks and beginning with "b" are called "best
tracks" or
> in
> > > >> other
> > > >> words the analysis/"observed" track.
> > > >>
> > > >> Hope this helps get you going in the right direction again.
> > > >> Cheers, Tara
> > > >>
> > > >>
> > > >> On Wed, May 24, 2017 at 12:52 PM, Xinxia Song via RT <
> > met_help at ucar.edu
> > > >
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > > >> >
> > > >> > Hi Tara,
> > > >> >
> > > >> >
> > > >> > I just a little confused with the track information. First,
it has
> > two
> > > >> > folders, one is track_data and another is track_data_atcf.
Should
> I
> > > edit
> > > >> > both or just one? Then within the track_data folder, it has
amlq*
> > and
> > > >> bmlq*
> > > >> > files. which file should I edit And the end is from 0001 to
0280,
> > what
> > > >> does
> > > >> > this mean? And when I open the file, it has many columns,
could
> you
> > > help
> > > >> me
> > > >> > to find out the critical columns like timestep, lat, lon
and
> cyclone
> > > id?
> > > >> >
> > > >> > Below is the first line of amlq2014123118.gfso.0005:
> > > >> >
> > > >> >
> > > >> > ML, 0005, 2014120112_F000_280S_0560W_FOF, 2014120112, 03,
GFSO,
> > 000,
> > > >> > 280S, 560W, 12, 1009, XX, 34, NEQ, 0000, 0000, 0000,
0000,
> 1011,
> > > >> 178,
> > > >> > -99, 148, 77, -99, -9999, -9999, -106, -90, -35, -39,
0088
> > > >> >
> > > >> >
> > > >> > Thanks,
> > > >> >
> > > >> >
> > > >> > Xinxia
> > > >> >
> > > >> > ________________________________
> > > >> > From: Tara Jensen via RT <met_help at ucar.edu>
> > > >> > Sent: Wednesday, May 24, 2017 12:09:09 PM
> > > >> > To: minnawin at ucar.edu
> > > >> > Cc: Xinxia_Song at outlook.com
> > > >> > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply:
> METplus-filtering
> > > one
> > > >> > days' worth of data based on area
> > > >> >
> > > >> > Hi Xinxia,
> > > >> >
> > > >> > Tara here. Minna is out until next week, as am I, and much
of our
> > > >> met_help
> > > >> > staff. We will look into this further next Wed or Thur.
> > > >> >
> > > >> > I have not had time to run through the example you and
Minna are
> > > working
> > > >> on
> > > >> > so really don't understand how you have it set-up for
debugging.
> If
> > > you
> > > >> > haven't done so yet, I'd suggest running just 1 extra
tropical
> > cyclone
> > > >> > track through your system (assuming this is what you refer
to as
> the
> > > >> > Fortran code) and through MET+. You could do so by
deleting all
> > > tracks
> > > >> > except one from the input track files (making sure it's the
same
> > > track).
> > > >> I
> > > >> > would suggest using your plotting package to plot both the
netcdf
> > > output
> > > >> of
> > > >> > the Fortran code and MET+.
> > > >> >
> > > >> > If there's a difference between the fields extracted, then
we
> have a
> > > >> good
> > > >> > place to start. If there isn't a difference, then add
another
> track
> > > in,
> > > >> > run the two systems, compare etc...
> > > >> >
> > > >> > Cheers, Tara
> > > >> >
> > > >> > On Wed, May 24, 2017 at 7:41 AM, Xinxia Song via RT <
> > > met_help at ucar.edu>
> > > >> > wrote:
> > > >> >
> > > >> > >
> > > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=80483 >
> > > >> > >
> > > >> > > Hi Minna,
> > > >> > >
> > > >> > >
> > > >> > > I think the MET doesn't exclude the points fall outside
the
> > boundary
> > > >> > cause
> > > >> > > we have more cyclones tracked in MET than in Fortran
code. Is
> > there
> > > >> any
> > > >> > > possibility we exclude them successfully? Otherwise we
need to
> > > modify
> > > >> the
> > > >> > > track file for Fortran code and Fortran code itself.
> > > >> > >
> > > >> > >
> > > >> > > Thanks,
> > > >> > >
> > > >> > >
> > > >> > > Xinxia
> > > >> > >
> > > >> > > ________________________________
> > > >> > > From: Minna Win via RT <met_help at ucar.edu>
> > > >> > > Sent: Monday, May 22, 2017 6:45:16 PM
> > > >> > > Cc: Xinxia_Song at outlook.com
> > > >> > > Subject: Re: [rt.rap.ucar.edu #80483] AutoReply:
> > METplus-filtering
> > > >> one
> > > >> > > days' worth of data based on area
> > > >> > >
> > > >> > > Hi Xinxia,
> > > >> > >
> > > >> > > From what I've found thus far, it looks like the masking
by
> region
> > > is
> > > >> > > working as expected (this uses the MET tool TC-Stat). In
some
> > > cases,
> > > >> > there
> > > >> > > is a point (or points) that lie outside the boundary
because
> they
> > > >> belong
> > > >> > to
> > > >> > > a storm track which has an init time (with lead hour =0)
within
> > the
> > > >> > > boundary (this is consistent with the -out_init_mask
argument
> used
> > > to
> > > >> do
> > > >> > > the masking). The METplus code does not perform any
"surgical"
> > > >> removal
> > > >> > of
> > > >> > > these few outliers. We get even more outliers when we
perform
> > > >> regridding
> > > >> > > with the MET tool regrid_data_plane. This uses the atrack
and
> > btrack
> > > >> > > lon,lat values and interpolates points using the nearest
> neighbor
> > > >> > > technique. We are requesting 60 lons and 60 lats total
for the
> > > >> regridded
> > > >> > > tiles, so if we have a few outliers, by the time we
finish
> > > regridding
> > > >> we
> > > >> > > end up with even more points that are outside the
boundary.
> > > >> > >
> > > >> > > Is this what you were referring to when you thought the
region
> > > wasn't
> > > >> > > getting masked? I used the values in your
constants_pdef.py
> file
> > > and
> > > >> > they
> > > >> > > look OK.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Minna
> > > >> > >
> > > >> > > ---------------
> > > >> > > Minna Win
> > > >> > > NCAR
> > > >> > > Research Applications Lab
> > > >> > > Phone: 303-497-8423
> > > >> > > Fax: 302-497-8401
> > > >> > >
> > > >> > >
> > > >> > > On Mon, May 22, 2017 at 2:23 PM, Xinxia Song <
> > > Xinxia_Song at outlook.com
> > > >> >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hi Minna,
> > > >> > > >
> > > >> > > > I use the constants_pdef.py to shrink the MET region
the the
> one
> > > >> that
> > > >> > > > Fortran code uses. But seems it doesn't do it
correctly. Could
> > you
> > > >> help
> > > >> > > to
> > > >> > > > check the constants_pdef.py to see where is the
problem?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > > Xinxia
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >> > Tara Jensen
> > > >> > Project Manager II
> > > >> > NCAR RAL and DTC
> > > >> > PO Box 3000, Boulder, Colorado 80307 USA
> > > >> > +1 303-497-8479 jensen at ucar.edu
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >> Tara Jensen
> > > >> Project Manager II
> > > >> NCAR RAL and DTC
> > > >> PO Box 3000, Boulder, Colorado 80307 USA
> > > >> +1 303-497-8479 jensen at ucar.edu
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Tara Jensen
> > > > Project Manager II
> > > > NCAR RAL and DTC
> > > > PO Box 3000, Boulder, Colorado 80307 USA
> > > > +1 303-497-8479 <(303)%20497-8479> jensen at ucar.edu
> > > >
> > >
> > >
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Tara Jensen
> > > Project Manager II
> > > NCAR RAL and DTC
> > > PO Box 3000, Boulder, Colorado 80307 USA
> > > +1 303-497-8479 jensen at ucar.edu
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Tara Jensen
> > Project Manager II
> > NCAR RAL and DTC
> > PO Box 3000, Boulder, Colorado 80307 USA
> > +1 303-497-8479 jensen at ucar.edu
> >
> >
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tara Jensen
> Project Manager II
> NCAR RAL and DTC
> PO Box 3000, Boulder, Colorado 80307 USA
> +1 303-497-8479 jensen at ucar.edu
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tara Jensen
Project Manager II
NCAR RAL and DTC
PO Box 3000, Boulder, Colorado 80307 USA
+1 303-497-8479 jensen at ucar.edu
------------------------------------------------
More information about the Met_help
mailing list