[Met_help] [rt.rap.ucar.edu #91097] History for
John Halley Gotway via RT
met_help at ucar.edu
Mon Jul 22 11:03:12 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
To Whom It May Concern:
I first report regrid_data_plane in ticket #90550. It has been resolved
and I was able to plot CMAQ mapped G16 AOD. Then the ticket was closed
I was able to produce CMAQ mapped G16 AOD till yesterday.
[image: image.png]
But today I have problem on the mapped G16 AOD to CMAQ. The post mapped
AOD is not right.
[image: image.png]
Disregard about the title, they are all using high quality AOD. Note it is
okay when I mapped to HYSPLIT grid today
[image: image.png]
I also repeat the processes on 20190709 and the result is the same.
Does MET8.1 being changed between yesterday and today? Can you try based
on the source data and model grid described below (on Tide).
Thank you for your help.
Ho-Chun
p.s.
regrid_data_plane
/meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-L2-AODC-M6_G16_s20191902301314_e20191902304087_c20191902305575.nc
/naqfc/save/Ho-Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
/meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_20190709_23_high.nc
-field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc 0
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Wed Jul 17 06:07:15 2019
To Whom It May Concern:
I repeat the regrid_data_plane and plot_data_plane today and the
mapping is
back to normal now. I am confused and do not know what happened.
Will
monitor the cronjob for a few day.
Ho-Chun
On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
<met_help at ucar.edu>
wrote:
> Greetings,
>
> This message has been automatically generated in response to the
creation
> of a trouble ticket regarding:
> "",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket
has been
> assigned an ID of [rt.rap.ucar.edu #91097].
>
> Please include the string:
>
> [rt.rap.ucar.edu #91097]
>
> in the subject line of all future correspondence about this issue.
To do
> so, you may reply to this message.
>
> For more information, please see:
>
> MET Online Tutorial:
>
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
>
> MET Users Guide:
> https://www.dtcenter.org/met/users/docs/overview.php
>
> MET FAQs:
> https://www.dtcenter.org/met/users/support/faqs/index.php
>
> MET-Help Email Archive:
> http://mailman.ucar.edu/pipermail/met_help
>
> Thank you,
> met_help at ucar.edu
>
>
-------------------------------------------------------------------------
> To Whom It May Concern:
>
> I first report regrid_data_plane in ticket #90550. It has been
resolved
> and I was able to plot CMAQ mapped G16 AOD. Then the ticket was
closed
>
> I was able to produce CMAQ mapped G16 AOD till yesterday.
> [image: image.png]
>
> But today I have problem on the mapped G16 AOD to CMAQ. The post
mapped
> AOD is not right.
> [image: image.png]
>
> Disregard about the title, they are all using high quality AOD.
Note it is
> okay when I mapped to HYSPLIT grid today
>
> [image: image.png]
>
> I also repeat the processes on 20190709 and the result is the same.
>
> Does MET8.1 being changed between yesterday and today? Can you try
based
> on the source data and model grid described below (on Tide).
>
> Thank you for your help.
>
> Ho-Chun
>
> p.s.
>
> regrid_data_plane
>
> /meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-L2-AODC-
M6_G16_s20191902301314_e20191902304087_
> c20191902305575.nc
> /naqfc/save/Ho-Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
>
> /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> 20190709_23_high.nc
> -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc 0
>
>
------------------------------------------------
Subject:
From: Howard Soh
Time: Wed Jul 17 09:06:29 2019
The GOES file itself contains information for the spatial coordinates
but does not have the lat/lon values. So regrid_data_plane computes
the lat/lon (which took about 1 minute for CONUS) and saves two
temporary files to skip the lat/lon computing next time. They are 1)
NetCDF file with lat/lon and 2) a text file with grid mapping for the
target grid. They are saved at "/tmp" or at $MET_TMP_DIR if
$MET_TMP_DIR is defined. The temporary file names begin with "CONUS"
or "Full" and end with ".nc" or ".grid_map". If the problem is
consistent, please find and delete them. They will be re-created. If
you can not delete them because you are not owner, please set
MET_TMP_DIR environment variable to the directory where you can write.
It will be helpful if you send them to me before deleting them.
Cheers,
Howard
On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> To Whom It May Concern:
>
> I repeat the regrid_data_plane and plot_data_plane today and the
> mapping is
> back to normal now. I am confused and do not know what happened.
> Will
> monitor the cronjob for a few day.
>
> Ho-Chun
>
>
>
> On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> <met_help at ucar.edu>
> wrote:
>
> > Greetings,
> >
> > This message has been automatically generated in response to the
> > creation
> > of a trouble ticket regarding:
> > "",
> > a summary of which appears below.
> >
> > There is no need to reply to this message right now. Your ticket
has
> > been
> > assigned an ID of [rt.rap.ucar.edu #91097].
> >
> > Please include the string:
> >
> > [rt.rap.ucar.edu #91097]
> >
> > in the subject line of all future correspondence about this issue.
To
> > do
> > so, you may reply to this message.
> >
> > For more information, please see:
> >
> > MET Online Tutorial:
> >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> >
> > MET Users Guide:
> > https://www.dtcenter.org/met/users/docs/overview.php
> >
> > MET FAQs:
> > https://www.dtcenter.org/met/users/support/faqs/index.php
> >
> > MET-Help Email Archive:
> > http://mailman.ucar.edu/pipermail/met_help
> >
> > Thank you,
> > met_help at ucar.edu
> >
> >
-------------------------------------------------------------------------
> > To Whom It May Concern:
> >
> > I first report regrid_data_plane in ticket #90550. It has been
> > resolved
> > and I was able to plot CMAQ mapped G16 AOD. Then the ticket was
> > closed
> >
> > I was able to produce CMAQ mapped G16 AOD till yesterday.
> > [image: image.png]
> >
> > But today I have problem on the mapped G16 AOD to CMAQ. The post
> > mapped
> > AOD is not right.
> > [image: image.png]
> >
> > Disregard about the title, they are all using high quality AOD.
Note
> > it is
> > okay when I mapped to HYSPLIT grid today
> >
> > [image: image.png]
> >
> > I also repeat the processes on 20190709 and the result is the
same.
> >
> > Does MET8.1 being changed between yesterday and today? Can you
try
> > based
> > on the source data and model grid described below (on Tide).
> >
> > Thank you for your help.
> >
> > Ho-Chun
> >
> > p.s.
> >
> > regrid_data_plane
> >
> > /meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-L2-
AODC-
> > M6_G16_s20191902301314_e20191902304087_
> > c20191902305575.nc
> > /naqfc/save/Ho-
Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> >
> > /meso2/noscrub/Ho-
> > Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> > 20190709_23_high.nc
> > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc 0
> >
> >
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Wed Jul 17 10:17:04 2019
Hi, Howard:
When we work on it at the beginning, we do have the pixel coordinate
file
called "g16_conus_latlon_2km_20180620.dat" that contains the lat lon
of
each pixel (fixed in space). I am curious why Metplus gave up -coord
option for using g16_conus_latlon_2km_20180620.dat? Shouldn't that
give
you exact (lat lon) information?
However, I bet you must have a good reason to go with current option.
I will test using the $MET_TMP_DIR in my script. Please wait till I
can
successfully managing the two temporary files. Thank you.
Ho-Chun
On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT <met_help at ucar.edu>
wrote:
> The GOES file itself contains information for the spatial
coordinates but
> does not have the lat/lon values. So regrid_data_plane computes the
lat/lon
> (which took about 1 minute for CONUS) and saves two temporary files
to skip
> the lat/lon computing next time. They are 1) NetCDF file with
lat/lon and
> 2) a text file with grid mapping for the target grid. They are saved
at
> "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The temporary
file
> names begin with "CONUS" or "Full" and end with ".nc" or
".grid_map". If
> the problem is consistent, please find and delete them. They will be
> re-created. If you can not delete them because you are not owner,
please
> set MET_TMP_DIR environment variable to the directory where you can
write.
> It will be helpful if you send them to me before deleting them.
>
> Cheers,
> Howard
>
> On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> > To Whom It May Concern:
> >
> > I repeat the regrid_data_plane and plot_data_plane today and the
> > mapping is
> > back to normal now. I am confused and do not know what happened.
> > Will
> > monitor the cronjob for a few day.
> >
> > Ho-Chun
> >
> >
> >
> > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> > > Greetings,
> > >
> > > This message has been automatically generated in response to the
> > > creation
> > > of a trouble ticket regarding:
> > > "",
> > > a summary of which appears below.
> > >
> > > There is no need to reply to this message right now. Your
ticket has
> > > been
> > > assigned an ID of [rt.rap.ucar.edu #91097].
> > >
> > > Please include the string:
> > >
> > > [rt.rap.ucar.edu #91097]
> > >
> > > in the subject line of all future correspondence about this
issue. To
> > > do
> > > so, you may reply to this message.
> > >
> > > For more information, please see:
> > >
> > > MET Online Tutorial:
> > >
> https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> > >
> > > MET Users Guide:
> > > https://www.dtcenter.org/met/users/docs/overview.php
> > >
> > > MET FAQs:
> > > https://www.dtcenter.org/met/users/support/faqs/index.php
> > >
> > > MET-Help Email Archive:
> > > http://mailman.ucar.edu/pipermail/met_help
> > >
> > > Thank you,
> > > met_help at ucar.edu
> > >
> > >
>
-------------------------------------------------------------------------
> > > To Whom It May Concern:
> > >
> > > I first report regrid_data_plane in ticket #90550. It has been
> > > resolved
> > > and I was able to plot CMAQ mapped G16 AOD. Then the ticket was
> > > closed
> > >
> > > I was able to produce CMAQ mapped G16 AOD till yesterday.
> > > [image: image.png]
> > >
> > > But today I have problem on the mapped G16 AOD to CMAQ. The
post
> > > mapped
> > > AOD is not right.
> > > [image: image.png]
> > >
> > > Disregard about the title, they are all using high quality AOD.
Note
> > > it is
> > > okay when I mapped to HYSPLIT grid today
> > >
> > > [image: image.png]
> > >
> > > I also repeat the processes on 20190709 and the result is the
same.
> > >
> > > Does MET8.1 being changed between yesterday and today? Can you
try
> > > based
> > > on the source data and model grid described below (on Tide).
> > >
> > > Thank you for your help.
> > >
> > > Ho-Chun
> > >
> > > p.s.
> > >
> > > regrid_data_plane
> > >
> > > /meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-L2-
AODC-
> > > M6_G16_s20191902301314_e20191902304087_
> > > c20191902305575.nc
> > > /naqfc/save/Ho-
Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> > >
> > > /meso2/noscrub/Ho-
> > > Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> > > 20190709_23_high.nc
> > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc 0
> > >
> > >
>
>
>
>
------------------------------------------------
Subject:
From: Howard Soh
Time: Wed Jul 17 10:42:53 2019
MET did not give up using the pixel coordinate file (NetCDF or binary
file like
"g16_conus_latlon_2km_20180620.dat"). The command line argument "-
coord" was removed at V8.1 but the environment variable
"MET_GEOSTATIONARY_DATA" was introduced. If "MET_GEOSTATIONARY_DATA"
is defined and the file exists, regrid_data_plane reads the coordinate
data file instead of computing.
Some users were confused with command line option "-coord" because
"g16_conus_latlon_2km_20180620.dat" was not part of MET and did not
know where to get. So we changed the default behavior to compute
lat/lon.
Cheers,
Howard
On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
> Hi, Howard:
>
> When we work on it at the beginning, we do have the pixel coordinate
> file
> called "g16_conus_latlon_2km_20180620.dat" that contains the lat lon
> of
> each pixel (fixed in space). I am curious why Metplus gave up
-coord
> option for using g16_conus_latlon_2km_20180620.dat? Shouldn't that
> give
> you exact (lat lon) information?
>
> However, I bet you must have a good reason to go with current
option.
>
> I will test using the $MET_TMP_DIR in my script. Please wait till I
> can
> successfully managing the two temporary files. Thank you.
>
> Ho-Chun
>
> On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
<met_help at ucar.edu>
> wrote:
>
> > The GOES file itself contains information for the spatial
coordinates
> > but
> > does not have the lat/lon values. So regrid_data_plane computes
the
> > lat/lon
> > (which took about 1 minute for CONUS) and saves two temporary
files
> > to skip
> > the lat/lon computing next time. They are 1) NetCDF file with
lat/lon
> > and
> > 2) a text file with grid mapping for the target grid. They are
saved
> > at
> > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
temporary
> > file
> > names begin with "CONUS" or "Full" and end with ".nc" or
".grid_map".
> > If
> > the problem is consistent, please find and delete them. They will
be
> > re-created. If you can not delete them because you are not owner,
> > please
> > set MET_TMP_DIR environment variable to the directory where you
can
> > write.
> > It will be helpful if you send them to me before deleting them.
> >
> > Cheers,
> > Howard
> >
> > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> > > To Whom It May Concern:
> > >
> > > I repeat the regrid_data_plane and plot_data_plane today and the
> > > mapping is
> > > back to normal now. I am confused and do not know what
happened.
> > > Will
> > > monitor the cronjob for a few day.
> > >
> > > Ho-Chun
> > >
> > >
> > >
> > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> > > <met_help at ucar.edu>
> > > wrote:
> > >
> > > > Greetings,
> > > >
> > > > This message has been automatically generated in response to
the
> > > > creation
> > > > of a trouble ticket regarding:
> > > > "",
> > > > a summary of which appears below.
> > > >
> > > > There is no need to reply to this message right now. Your
ticket
> > > > has
> > > > been
> > > > assigned an ID of [rt.rap.ucar.edu #91097].
> > > >
> > > > Please include the string:
> > > >
> > > > [rt.rap.ucar.edu #91097]
> > > >
> > > > in the subject line of all future correspondence about this
> > > > issue. To
> > > > do
> > > > so, you may reply to this message.
> > > >
> > > > For more information, please see:
> > > >
> > > > MET Online Tutorial:
> > > >
> >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> > > >
> > > > MET Users Guide:
> > > > https://www.dtcenter.org/met/users/docs/overview.php
> > > >
> > > > MET FAQs:
> > > > https://www.dtcenter.org/met/users/support/faqs/index.php
> > > >
> > > > MET-Help Email Archive:
> > > > http://mailman.ucar.edu/pipermail/met_help
> > > >
> > > > Thank you,
> > > > met_help at ucar.edu
> > > >
> > > >
> >
-------------------------------------------------------------------------
> > > > To Whom It May Concern:
> > > >
> > > > I first report regrid_data_plane in ticket #90550. It has
been
> > > > resolved
> > > > and I was able to plot CMAQ mapped G16 AOD. Then the ticket
was
> > > > closed
> > > >
> > > > I was able to produce CMAQ mapped G16 AOD till yesterday.
> > > > [image: image.png]
> > > >
> > > > But today I have problem on the mapped G16 AOD to CMAQ. The
post
> > > > mapped
> > > > AOD is not right.
> > > > [image: image.png]
> > > >
> > > > Disregard about the title, they are all using high quality
AOD.
> > > > Note
> > > > it is
> > > > okay when I mapped to HYSPLIT grid today
> > > >
> > > > [image: image.png]
> > > >
> > > > I also repeat the processes on 20190709 and the result is the
> > > > same.
> > > >
> > > > Does MET8.1 being changed between yesterday and today? Can
you
> > > > try
> > > > based
> > > > on the source data and model grid described below (on Tide).
> > > >
> > > > Thank you for your help.
> > > >
> > > > Ho-Chun
> > > >
> > > > p.s.
> > > >
> > > > regrid_data_plane
> > > >
> > > > /meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
L2-
> > > > AODC-
> > > > M6_G16_s20191902301314_e20191902304087_
> > > > c20191902305575.nc
> > > > /naqfc/save/Ho-
> > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> > > >
> > > > /meso2/noscrub/Ho-
> > > > Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> > > > 20190709_23_high.nc
> > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc 0
> > > >
> > > >
> >
> >
> >
> >
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Thu Jul 18 07:08:54 2019
Hi, Howard:
I defined the $MET_TMP_DIR and delete everything before I begin using
regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA point to the
location of g16_conus_latlon_2km_20180620.dat. Today's cronjob seems
to
produce a correct G16 AOD mapping.
I am developing this MET verification product targeted for operational
implementation. Thus, this uncertainty of incorrect mapping can not
be
allowed to happen once the verification tool is in NCO's hand. Could
you
elaborate of the reason behind the problem I encountered? and by using
$MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above will
eliminate
the possibility of re-occurrence of this problem. What is
On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT <met_help at ucar.edu>
wrote:
> MET did not give up using the pixel coordinate file (NetCDF or
binary file
> like
> "g16_conus_latlon_2km_20180620.dat"). The command line argument "-
coord"
> was removed at V8.1 but the environment variable
"MET_GEOSTATIONARY_DATA"
> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and the file
exists,
> regrid_data_plane reads the coordinate data file instead of
computing.
>
> Some users were confused with command line option "-coord" because
> "g16_conus_latlon_2km_20180620.dat" was not part of MET and did not
know
> where to get. So we changed the default behavior to compute lat/lon.
>
> Cheers,
> Howard
>
> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
> > Hi, Howard:
> >
> > When we work on it at the beginning, we do have the pixel
coordinate
> > file
> > called "g16_conus_latlon_2km_20180620.dat" that contains the lat
lon
> > of
> > each pixel (fixed in space). I am curious why Metplus gave up
-coord
> > option for using g16_conus_latlon_2km_20180620.dat? Shouldn't
that
> > give
> > you exact (lat lon) information?
> >
> > However, I bet you must have a good reason to go with current
option.
> >
> > I will test using the $MET_TMP_DIR in my script. Please wait till
I
> > can
> > successfully managing the two temporary files. Thank you.
> >
> > Ho-Chun
> >
> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > The GOES file itself contains information for the spatial
coordinates
> > > but
> > > does not have the lat/lon values. So regrid_data_plane computes
the
> > > lat/lon
> > > (which took about 1 minute for CONUS) and saves two temporary
files
> > > to skip
> > > the lat/lon computing next time. They are 1) NetCDF file with
lat/lon
> > > and
> > > 2) a text file with grid mapping for the target grid. They are
saved
> > > at
> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
temporary
> > > file
> > > names begin with "CONUS" or "Full" and end with ".nc" or
".grid_map".
> > > If
> > > the problem is consistent, please find and delete them. They
will be
> > > re-created. If you can not delete them because you are not
owner,
> > > please
> > > set MET_TMP_DIR environment variable to the directory where you
can
> > > write.
> > > It will be helpful if you send them to me before deleting them.
> > >
> > > Cheers,
> > > Howard
> > >
> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> > > > To Whom It May Concern:
> > > >
> > > > I repeat the regrid_data_plane and plot_data_plane today and
the
> > > > mapping is
> > > > back to normal now. I am confused and do not know what
happened.
> > > > Will
> > > > monitor the cronjob for a few day.
> > > >
> > > > Ho-Chun
> > > >
> > > >
> > > >
> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> > > > <met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Greetings,
> > > > >
> > > > > This message has been automatically generated in response to
the
> > > > > creation
> > > > > of a trouble ticket regarding:
> > > > > "",
> > > > > a summary of which appears below.
> > > > >
> > > > > There is no need to reply to this message right now. Your
ticket
> > > > > has
> > > > > been
> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
> > > > >
> > > > > Please include the string:
> > > > >
> > > > > [rt.rap.ucar.edu #91097]
> > > > >
> > > > > in the subject line of all future correspondence about this
> > > > > issue. To
> > > > > do
> > > > > so, you may reply to this message.
> > > > >
> > > > > For more information, please see:
> > > > >
> > > > > MET Online Tutorial:
> > > > >
> > >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> > > > >
> > > > > MET Users Guide:
> > > > > https://www.dtcenter.org/met/users/docs/overview.php
> > > > >
> > > > > MET FAQs:
> > > > > https://www.dtcenter.org/met/users/support/faqs/index.php
> > > > >
> > > > > MET-Help Email Archive:
> > > > > http://mailman.ucar.edu/pipermail/met_help
> > > > >
> > > > > Thank you,
> > > > > met_help at ucar.edu
> > > > >
> > > > >
> > >
>
-------------------------------------------------------------------------
> > > > > To Whom It May Concern:
> > > > >
> > > > > I first report regrid_data_plane in ticket #90550. It has
been
> > > > > resolved
> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the ticket
was
> > > > > closed
> > > > >
> > > > > I was able to produce CMAQ mapped G16 AOD till yesterday.
> > > > > [image: image.png]
> > > > >
> > > > > But today I have problem on the mapped G16 AOD to CMAQ. The
post
> > > > > mapped
> > > > > AOD is not right.
> > > > > [image: image.png]
> > > > >
> > > > > Disregard about the title, they are all using high quality
AOD.
> > > > > Note
> > > > > it is
> > > > > okay when I mapped to HYSPLIT grid today
> > > > >
> > > > > [image: image.png]
> > > > >
> > > > > I also repeat the processes on 20190709 and the result is
the
> > > > > same.
> > > > >
> > > > > Does MET8.1 being changed between yesterday and today? Can
you
> > > > > try
> > > > > based
> > > > > on the source data and model grid described below (on Tide).
> > > > >
> > > > > Thank you for your help.
> > > > >
> > > > > Ho-Chun
> > > > >
> > > > > p.s.
> > > > >
> > > > > regrid_data_plane
> > > > >
> > > > > /meso2/noscrub/Ho-Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
L2-
> > > > > AODC-
> > > > > M6_G16_s20191902301314_e20191902304087_
> > > > > c20191902305575.nc
> > > > > /naqfc/save/Ho-
> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> > > > >
> > > > > /meso2/noscrub/Ho-
> > > > > Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> > > > > 20190709_23_high.nc
> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1 -qc
0
> > > > >
> > > > >
> > >
> > >
> > >
> > >
>
>
>
>
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Thu Jul 18 07:18:36 2019
Hi,
Sorry to send it too early. I want to know in your expert opinion
that the
usage of $MET_TMP_DIR and $MET_GEOSTATIONARY_DATA will prevent similar
problem from happening.
Also, can you clarify current regrid_data_plane with
-qc 0, is to use ADO with quality flag=0 ONLY
-qc 1, is to use ADO with quality flag=1 ONLY
-qc 2, is to use ADO with quality flag=2 ONLY
If it is the case, then I think it might have to be changed to
-qc 0, is to use ADO with quality flag<=0, i.e., quality flag=0.
-qc 1, is to use ADO with quality flag<=1, i.e., quality flag=0 and
quality
flag=1.
-qc 2, is to use ADO with quality flag<=2, i.e., quality flag=0, 1,
and 2
(All AOD)
We might have to bring John and Tara in for the changes.
Ho-Chun
On Thu, Jul 18, 2019 at 9:08 AM Ho-Chun Huang - NOAA Affiliate <
ho-chun.huang at noaa.gov> wrote:
> Hi, Howard:
>
> I defined the $MET_TMP_DIR and delete everything before I begin
using
> regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA point to
the
> location of g16_conus_latlon_2km_20180620.dat. Today's cronjob
seems to
> produce a correct G16 AOD mapping.
>
> I am developing this MET verification product targeted for
operational
> implementation. Thus, this uncertainty of incorrect mapping can not
be
> allowed to happen once the verification tool is in NCO's hand.
Could you
> elaborate of the reason behind the problem I encountered? and by
using
> $MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above will
eliminate
> the possibility of re-occurrence of this problem. What is
>
> On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT
<met_help at ucar.edu>
> wrote:
>
>> MET did not give up using the pixel coordinate file (NetCDF or
binary
>> file like
>> "g16_conus_latlon_2km_20180620.dat"). The command line argument "-
coord"
>> was removed at V8.1 but the environment variable
"MET_GEOSTATIONARY_DATA"
>> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and the file
exists,
>> regrid_data_plane reads the coordinate data file instead of
computing.
>>
>> Some users were confused with command line option "-coord" because
>> "g16_conus_latlon_2km_20180620.dat" was not part of MET and did not
know
>> where to get. So we changed the default behavior to compute
lat/lon.
>>
>> Cheers,
>> Howard
>>
>> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
>> > Hi, Howard:
>> >
>> > When we work on it at the beginning, we do have the pixel
coordinate
>> > file
>> > called "g16_conus_latlon_2km_20180620.dat" that contains the lat
lon
>> > of
>> > each pixel (fixed in space). I am curious why Metplus gave up
-coord
>> > option for using g16_conus_latlon_2km_20180620.dat? Shouldn't
that
>> > give
>> > you exact (lat lon) information?
>> >
>> > However, I bet you must have a good reason to go with current
option.
>> >
>> > I will test using the $MET_TMP_DIR in my script. Please wait
till I
>> > can
>> > successfully managing the two temporary files. Thank you.
>> >
>> > Ho-Chun
>> >
>> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
<met_help at ucar.edu>
>> > wrote:
>> >
>> > > The GOES file itself contains information for the spatial
coordinates
>> > > but
>> > > does not have the lat/lon values. So regrid_data_plane computes
the
>> > > lat/lon
>> > > (which took about 1 minute for CONUS) and saves two temporary
files
>> > > to skip
>> > > the lat/lon computing next time. They are 1) NetCDF file with
lat/lon
>> > > and
>> > > 2) a text file with grid mapping for the target grid. They are
saved
>> > > at
>> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
temporary
>> > > file
>> > > names begin with "CONUS" or "Full" and end with ".nc" or
".grid_map".
>> > > If
>> > > the problem is consistent, please find and delete them. They
will be
>> > > re-created. If you can not delete them because you are not
owner,
>> > > please
>> > > set MET_TMP_DIR environment variable to the directory where you
can
>> > > write.
>> > > It will be helpful if you send them to me before deleting them.
>> > >
>> > > Cheers,
>> > > Howard
>> > >
>> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
>> > > > To Whom It May Concern:
>> > > >
>> > > > I repeat the regrid_data_plane and plot_data_plane today and
the
>> > > > mapping is
>> > > > back to normal now. I am confused and do not know what
happened.
>> > > > Will
>> > > > monitor the cronjob for a few day.
>> > > >
>> > > > Ho-Chun
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
>> > > > <met_help at ucar.edu>
>> > > > wrote:
>> > > >
>> > > > > Greetings,
>> > > > >
>> > > > > This message has been automatically generated in response
to the
>> > > > > creation
>> > > > > of a trouble ticket regarding:
>> > > > > "",
>> > > > > a summary of which appears below.
>> > > > >
>> > > > > There is no need to reply to this message right now. Your
ticket
>> > > > > has
>> > > > > been
>> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
>> > > > >
>> > > > > Please include the string:
>> > > > >
>> > > > > [rt.rap.ucar.edu #91097]
>> > > > >
>> > > > > in the subject line of all future correspondence about this
>> > > > > issue. To
>> > > > > do
>> > > > > so, you may reply to this message.
>> > > > >
>> > > > > For more information, please see:
>> > > > >
>> > > > > MET Online Tutorial:
>> > > > >
>> > >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
>> > > > >
>> > > > > MET Users Guide:
>> > > > > https://www.dtcenter.org/met/users/docs/overview.php
>> > > > >
>> > > > > MET FAQs:
>> > > > >
https://www.dtcenter.org/met/users/support/faqs/index.php
>> > > > >
>> > > > > MET-Help Email Archive:
>> > > > > http://mailman.ucar.edu/pipermail/met_help
>> > > > >
>> > > > > Thank you,
>> > > > > met_help at ucar.edu
>> > > > >
>> > > > >
>> > >
>>
-------------------------------------------------------------------------
>> > > > > To Whom It May Concern:
>> > > > >
>> > > > > I first report regrid_data_plane in ticket #90550. It has
been
>> > > > > resolved
>> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the
ticket was
>> > > > > closed
>> > > > >
>> > > > > I was able to produce CMAQ mapped G16 AOD till yesterday.
>> > > > > [image: image.png]
>> > > > >
>> > > > > But today I have problem on the mapped G16 AOD to CMAQ.
The post
>> > > > > mapped
>> > > > > AOD is not right.
>> > > > > [image: image.png]
>> > > > >
>> > > > > Disregard about the title, they are all using high quality
AOD.
>> > > > > Note
>> > > > > it is
>> > > > > okay when I mapped to HYSPLIT grid today
>> > > > >
>> > > > > [image: image.png]
>> > > > >
>> > > > > I also repeat the processes on 20190709 and the result is
the
>> > > > > same.
>> > > > >
>> > > > > Does MET8.1 being changed between yesterday and today? Can
you
>> > > > > try
>> > > > > based
>> > > > > on the source data and model grid described below (on
Tide).
>> > > > >
>> > > > > Thank you for your help.
>> > > > >
>> > > > > Ho-Chun
>> > > > >
>> > > > > p.s.
>> > > > >
>> > > > > regrid_data_plane
>> > > > >
>> > > > > /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-L2-
>> > > > > AODC-
>> > > > > M6_G16_s20191902301314_e20191902304087_
>> > > > > c20191902305575.nc
>> > > > > /naqfc/save/Ho-
>> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
>> > > > >
>> > > > > /meso2/noscrub/Ho-
>> > > > > Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
>> > > > > 20190709_23_high.nc
>> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1
-qc 0
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>> > >
>>
>>
>>
>>
------------------------------------------------
Subject:
From: Howard Soh
Time: Thu Jul 18 14:45:16 2019
The git issues was created (https://github.com/NCAR/MET/issues/1168).
The -qc argument allows the list of QC values (comma separated,
without space): for example, "-qc 1,2" for QC value 1 or 2.
The alternative will be using
- "-qc 0"
- "-qc 0,1"
- "-qc 0,1,2"
Cheers,
Howard
On Thu Jul 18 07:18:36 2019, ho-chun.huang at noaa.gov wrote:
> Hi,
>
> Sorry to send it too early. I want to know in your expert opinion
> that the
> usage of $MET_TMP_DIR and $MET_GEOSTATIONARY_DATA will prevent
similar
> problem from happening.
>
> Also, can you clarify current regrid_data_plane with
>
> -qc 0, is to use ADO with quality flag=0 ONLY
> -qc 1, is to use ADO with quality flag=1 ONLY
> -qc 2, is to use ADO with quality flag=2 ONLY
>
> If it is the case, then I think it might have to be changed to
>
> -qc 0, is to use ADO with quality flag<=0, i.e., quality flag=0.
> -qc 1, is to use ADO with quality flag<=1, i.e., quality flag=0 and
> quality
> flag=1.
> -qc 2, is to use ADO with quality flag<=2, i.e., quality flag=0, 1,
> and 2
> (All AOD)
>
> We might have to bring John and Tara in for the changes.
>
> Ho-Chun
>
> On Thu, Jul 18, 2019 at 9:08 AM Ho-Chun Huang - NOAA Affiliate <
> ho-chun.huang at noaa.gov> wrote:
>
> > Hi, Howard:
> >
> > I defined the $MET_TMP_DIR and delete everything before I begin
using
> > regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA point to
> > the
> > location of g16_conus_latlon_2km_20180620.dat. Today's cronjob
seems
> > to
> > produce a correct G16 AOD mapping.
> >
> > I am developing this MET verification product targeted for
> > operational
> > implementation. Thus, this uncertainty of incorrect mapping can
not
> > be
> > allowed to happen once the verification tool is in NCO's hand.
Could
> > you
> > elaborate of the reason behind the problem I encountered? and by
> > using
> > $MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above will
> > eliminate
> > the possibility of re-occurrence of this problem. What is
> >
> > On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> >> MET did not give up using the pixel coordinate file (NetCDF or
> >> binary
> >> file like
> >> "g16_conus_latlon_2km_20180620.dat"). The command line argument
"-
> >> coord"
> >> was removed at V8.1 but the environment variable
> >> "MET_GEOSTATIONARY_DATA"
> >> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and the
file
> >> exists,
> >> regrid_data_plane reads the coordinate data file instead of
> >> computing.
> >>
> >> Some users were confused with command line option "-coord"
because
> >> "g16_conus_latlon_2km_20180620.dat" was not part of MET and did
not
> >> know
> >> where to get. So we changed the default behavior to compute
lat/lon.
> >>
> >> Cheers,
> >> Howard
> >>
> >> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
> >> > Hi, Howard:
> >> >
> >> > When we work on it at the beginning, we do have the pixel
> >> > coordinate
> >> > file
> >> > called "g16_conus_latlon_2km_20180620.dat" that contains the
lat
> >> > lon
> >> > of
> >> > each pixel (fixed in space). I am curious why Metplus gave up
> >> > -coord
> >> > option for using g16_conus_latlon_2km_20180620.dat? Shouldn't
> >> > that
> >> > give
> >> > you exact (lat lon) information?
> >> >
> >> > However, I bet you must have a good reason to go with current
> >> > option.
> >> >
> >> > I will test using the $MET_TMP_DIR in my script. Please wait
till
> >> > I
> >> > can
> >> > successfully managing the two temporary files. Thank you.
> >> >
> >> > Ho-Chun
> >> >
> >> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
> >> > <met_help at ucar.edu>
> >> > wrote:
> >> >
> >> > > The GOES file itself contains information for the spatial
> >> > > coordinates
> >> > > but
> >> > > does not have the lat/lon values. So regrid_data_plane
computes
> >> > > the
> >> > > lat/lon
> >> > > (which took about 1 minute for CONUS) and saves two temporary
> >> > > files
> >> > > to skip
> >> > > the lat/lon computing next time. They are 1) NetCDF file with
> >> > > lat/lon
> >> > > and
> >> > > 2) a text file with grid mapping for the target grid. They
are
> >> > > saved
> >> > > at
> >> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
> >> > > temporary
> >> > > file
> >> > > names begin with "CONUS" or "Full" and end with ".nc" or
> >> > > ".grid_map".
> >> > > If
> >> > > the problem is consistent, please find and delete them. They
> >> > > will be
> >> > > re-created. If you can not delete them because you are not
> >> > > owner,
> >> > > please
> >> > > set MET_TMP_DIR environment variable to the directory where
you
> >> > > can
> >> > > write.
> >> > > It will be helpful if you send them to me before deleting
them.
> >> > >
> >> > > Cheers,
> >> > > Howard
> >> > >
> >> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> >> > > > To Whom It May Concern:
> >> > > >
> >> > > > I repeat the regrid_data_plane and plot_data_plane today
and
> >> > > > the
> >> > > > mapping is
> >> > > > back to normal now. I am confused and do not know what
> >> > > > happened.
> >> > > > Will
> >> > > > monitor the cronjob for a few day.
> >> > > >
> >> > > > Ho-Chun
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> >> > > > <met_help at ucar.edu>
> >> > > > wrote:
> >> > > >
> >> > > > > Greetings,
> >> > > > >
> >> > > > > This message has been automatically generated in response
to
> >> > > > > the
> >> > > > > creation
> >> > > > > of a trouble ticket regarding:
> >> > > > > "",
> >> > > > > a summary of which appears below.
> >> > > > >
> >> > > > > There is no need to reply to this message right now.
Your
> >> > > > > ticket
> >> > > > > has
> >> > > > > been
> >> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
> >> > > > >
> >> > > > > Please include the string:
> >> > > > >
> >> > > > > [rt.rap.ucar.edu #91097]
> >> > > > >
> >> > > > > in the subject line of all future correspondence about
this
> >> > > > > issue. To
> >> > > > > do
> >> > > > > so, you may reply to this message.
> >> > > > >
> >> > > > > For more information, please see:
> >> > > > >
> >> > > > > MET Online Tutorial:
> >> > > > >
> >> > >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> >> > > > >
> >> > > > > MET Users Guide:
> >> > > > > https://www.dtcenter.org/met/users/docs/overview.php
> >> > > > >
> >> > > > > MET FAQs:
> >> > > > >
https://www.dtcenter.org/met/users/support/faqs/index.php
> >> > > > >
> >> > > > > MET-Help Email Archive:
> >> > > > > http://mailman.ucar.edu/pipermail/met_help
> >> > > > >
> >> > > > > Thank you,
> >> > > > > met_help at ucar.edu
> >> > > > >
> >> > > > >
> >> > >
> >>
-------------------------------------------------------------------------
> >> > > > > To Whom It May Concern:
> >> > > > >
> >> > > > > I first report regrid_data_plane in ticket #90550. It
has
> >> > > > > been
> >> > > > > resolved
> >> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the
ticket
> >> > > > > was
> >> > > > > closed
> >> > > > >
> >> > > > > I was able to produce CMAQ mapped G16 AOD till yesterday.
> >> > > > > [image: image.png]
> >> > > > >
> >> > > > > But today I have problem on the mapped G16 AOD to CMAQ.
The
> >> > > > > post
> >> > > > > mapped
> >> > > > > AOD is not right.
> >> > > > > [image: image.png]
> >> > > > >
> >> > > > > Disregard about the title, they are all using high
quality
> >> > > > > AOD.
> >> > > > > Note
> >> > > > > it is
> >> > > > > okay when I mapped to HYSPLIT grid today
> >> > > > >
> >> > > > > [image: image.png]
> >> > > > >
> >> > > > > I also repeat the processes on 20190709 and the result is
> >> > > > > the
> >> > > > > same.
> >> > > > >
> >> > > > > Does MET8.1 being changed between yesterday and today?
Can
> >> > > > > you
> >> > > > > try
> >> > > > > based
> >> > > > > on the source data and model grid described below (on
Tide).
> >> > > > >
> >> > > > > Thank you for your help.
> >> > > > >
> >> > > > > Ho-Chun
> >> > > > >
> >> > > > > p.s.
> >> > > > >
> >> > > > > regrid_data_plane
> >> > > > >
> >> > > > > /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
> >> > > > > L2-
> >> > > > > AODC-
> >> > > > > M6_G16_s20191902301314_e20191902304087_
> >> > > > > c20191902305575.nc
> >> > > > > /naqfc/save/Ho-
> >> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> >> > > > >
> >> > > > > /meso2/noscrub/Ho-
> >> > > > >
Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> >> > > > > 20190709_23_high.nc
> >> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v 1
-qc
> >> > > > > 0
> >> > > > >
> >> > > > >
> >> > >
> >> > >
> >> > >
> >> > >
> >>
> >>
> >>
> >>
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Fri Jul 19 06:09:48 2019
Hi, Howard:
A little bit confuse on *current* regrid_data_plane -qc option. You
said
with "-*qc 1,2*" is to "*use qc=1 OR qc=2*"? I believe each satellite
sensor pixels only have one quality flag value. Am I right that
"*qc=1 OR
qc=2" is to use pixel with EITHER quality flag =1 OR **quality flag
=2 ? *Interesting,
I will play with it.
If this is correct, then -qc=0,1 is to use AOD (qc=0 and 1) and -qc
0,1,2
is to use AOD(qc=0, 1, and 2). Then My request can be done in this
way, am
I correct?
Also, please comment on the use of $MET_TMP_DIR and
$MET_GEOSTATIONARY_DATA in previous email as I do not know the root of
cause of this mapping problem.
Thank you for your help.
Ho-Chun
On Thu, Jul 18, 2019 at 4:45 PM Howard Soh via RT <met_help at ucar.edu>
wrote:
> The git issues was created
(https://github.com/NCAR/MET/issues/1168).
>
> The -qc argument allows the list of QC values (comma separated,
without
> space): for example, "-qc 1,2" for QC value 1 or 2.
> The alternative will be using
> - "-qc 0"
> - "-qc 0,1"
> - "-qc 0,1,2"
>
> Cheers,
> Howard
>
> On Thu Jul 18 07:18:36 2019, ho-chun.huang at noaa.gov wrote:
> > Hi,
> >
> > Sorry to send it too early. I want to know in your expert opinion
> > that the
> > usage of $MET_TMP_DIR and $MET_GEOSTATIONARY_DATA will prevent
similar
> > problem from happening.
> >
> > Also, can you clarify current regrid_data_plane with
> >
> > -qc 0, is to use ADO with quality flag=0 ONLY
> > -qc 1, is to use ADO with quality flag=1 ONLY
> > -qc 2, is to use ADO with quality flag=2 ONLY
> >
> > If it is the case, then I think it might have to be changed to
> >
> > -qc 0, is to use ADO with quality flag<=0, i.e., quality flag=0.
> > -qc 1, is to use ADO with quality flag<=1, i.e., quality flag=0
and
> > quality
> > flag=1.
> > -qc 2, is to use ADO with quality flag<=2, i.e., quality flag=0,
1,
> > and 2
> > (All AOD)
> >
> > We might have to bring John and Tara in for the changes.
> >
> > Ho-Chun
> >
> > On Thu, Jul 18, 2019 at 9:08 AM Ho-Chun Huang - NOAA Affiliate <
> > ho-chun.huang at noaa.gov> wrote:
> >
> > > Hi, Howard:
> > >
> > > I defined the $MET_TMP_DIR and delete everything before I begin
using
> > > regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA point
to
> > > the
> > > location of g16_conus_latlon_2km_20180620.dat. Today's cronjob
seems
> > > to
> > > produce a correct G16 AOD mapping.
> > >
> > > I am developing this MET verification product targeted for
> > > operational
> > > implementation. Thus, this uncertainty of incorrect mapping can
not
> > > be
> > > allowed to happen once the verification tool is in NCO's hand.
Could
> > > you
> > > elaborate of the reason behind the problem I encountered? and by
> > > using
> > > $MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above will
> > > eliminate
> > > the possibility of re-occurrence of this problem. What is
> > >
> > > On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT
> > > <met_help at ucar.edu>
> > > wrote:
> > >
> > >> MET did not give up using the pixel coordinate file (NetCDF or
> > >> binary
> > >> file like
> > >> "g16_conus_latlon_2km_20180620.dat"). The command line argument
"-
> > >> coord"
> > >> was removed at V8.1 but the environment variable
> > >> "MET_GEOSTATIONARY_DATA"
> > >> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and the
file
> > >> exists,
> > >> regrid_data_plane reads the coordinate data file instead of
> > >> computing.
> > >>
> > >> Some users were confused with command line option "-coord"
because
> > >> "g16_conus_latlon_2km_20180620.dat" was not part of MET and did
not
> > >> know
> > >> where to get. So we changed the default behavior to compute
lat/lon.
> > >>
> > >> Cheers,
> > >> Howard
> > >>
> > >> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
> > >> > Hi, Howard:
> > >> >
> > >> > When we work on it at the beginning, we do have the pixel
> > >> > coordinate
> > >> > file
> > >> > called "g16_conus_latlon_2km_20180620.dat" that contains the
lat
> > >> > lon
> > >> > of
> > >> > each pixel (fixed in space). I am curious why Metplus gave
up
> > >> > -coord
> > >> > option for using g16_conus_latlon_2km_20180620.dat?
Shouldn't
> > >> > that
> > >> > give
> > >> > you exact (lat lon) information?
> > >> >
> > >> > However, I bet you must have a good reason to go with current
> > >> > option.
> > >> >
> > >> > I will test using the $MET_TMP_DIR in my script. Please wait
till
> > >> > I
> > >> > can
> > >> > successfully managing the two temporary files. Thank you.
> > >> >
> > >> > Ho-Chun
> > >> >
> > >> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
> > >> > <met_help at ucar.edu>
> > >> > wrote:
> > >> >
> > >> > > The GOES file itself contains information for the spatial
> > >> > > coordinates
> > >> > > but
> > >> > > does not have the lat/lon values. So regrid_data_plane
computes
> > >> > > the
> > >> > > lat/lon
> > >> > > (which took about 1 minute for CONUS) and saves two
temporary
> > >> > > files
> > >> > > to skip
> > >> > > the lat/lon computing next time. They are 1) NetCDF file
with
> > >> > > lat/lon
> > >> > > and
> > >> > > 2) a text file with grid mapping for the target grid. They
are
> > >> > > saved
> > >> > > at
> > >> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
> > >> > > temporary
> > >> > > file
> > >> > > names begin with "CONUS" or "Full" and end with ".nc" or
> > >> > > ".grid_map".
> > >> > > If
> > >> > > the problem is consistent, please find and delete them.
They
> > >> > > will be
> > >> > > re-created. If you can not delete them because you are not
> > >> > > owner,
> > >> > > please
> > >> > > set MET_TMP_DIR environment variable to the directory where
you
> > >> > > can
> > >> > > write.
> > >> > > It will be helpful if you send them to me before deleting
them.
> > >> > >
> > >> > > Cheers,
> > >> > > Howard
> > >> > >
> > >> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
> > >> > > > To Whom It May Concern:
> > >> > > >
> > >> > > > I repeat the regrid_data_plane and plot_data_plane today
and
> > >> > > > the
> > >> > > > mapping is
> > >> > > > back to normal now. I am confused and do not know what
> > >> > > > happened.
> > >> > > > Will
> > >> > > > monitor the cronjob for a few day.
> > >> > > >
> > >> > > > Ho-Chun
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
> > >> > > > <met_help at ucar.edu>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Greetings,
> > >> > > > >
> > >> > > > > This message has been automatically generated in
response to
> > >> > > > > the
> > >> > > > > creation
> > >> > > > > of a trouble ticket regarding:
> > >> > > > > "",
> > >> > > > > a summary of which appears below.
> > >> > > > >
> > >> > > > > There is no need to reply to this message right now.
Your
> > >> > > > > ticket
> > >> > > > > has
> > >> > > > > been
> > >> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
> > >> > > > >
> > >> > > > > Please include the string:
> > >> > > > >
> > >> > > > > [rt.rap.ucar.edu #91097]
> > >> > > > >
> > >> > > > > in the subject line of all future correspondence about
this
> > >> > > > > issue. To
> > >> > > > > do
> > >> > > > > so, you may reply to this message.
> > >> > > > >
> > >> > > > > For more information, please see:
> > >> > > > >
> > >> > > > > MET Online Tutorial:
> > >> > > > >
> > >> > >
> https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> > >> > > > >
> > >> > > > > MET Users Guide:
> > >> > > > > https://www.dtcenter.org/met/users/docs/overview.php
> > >> > > > >
> > >> > > > > MET FAQs:
> > >> > > > >
https://www.dtcenter.org/met/users/support/faqs/index.php
> > >> > > > >
> > >> > > > > MET-Help Email Archive:
> > >> > > > > http://mailman.ucar.edu/pipermail/met_help
> > >> > > > >
> > >> > > > > Thank you,
> > >> > > > > met_help at ucar.edu
> > >> > > > >
> > >> > > > >
> > >> > >
> > >>
>
-------------------------------------------------------------------------
> > >> > > > > To Whom It May Concern:
> > >> > > > >
> > >> > > > > I first report regrid_data_plane in ticket #90550. It
has
> > >> > > > > been
> > >> > > > > resolved
> > >> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the
ticket
> > >> > > > > was
> > >> > > > > closed
> > >> > > > >
> > >> > > > > I was able to produce CMAQ mapped G16 AOD till
yesterday.
> > >> > > > > [image: image.png]
> > >> > > > >
> > >> > > > > But today I have problem on the mapped G16 AOD to CMAQ.
The
> > >> > > > > post
> > >> > > > > mapped
> > >> > > > > AOD is not right.
> > >> > > > > [image: image.png]
> > >> > > > >
> > >> > > > > Disregard about the title, they are all using high
quality
> > >> > > > > AOD.
> > >> > > > > Note
> > >> > > > > it is
> > >> > > > > okay when I mapped to HYSPLIT grid today
> > >> > > > >
> > >> > > > > [image: image.png]
> > >> > > > >
> > >> > > > > I also repeat the processes on 20190709 and the result
is
> > >> > > > > the
> > >> > > > > same.
> > >> > > > >
> > >> > > > > Does MET8.1 being changed between yesterday and today?
Can
> > >> > > > > you
> > >> > > > > try
> > >> > > > > based
> > >> > > > > on the source data and model grid described below (on
Tide).
> > >> > > > >
> > >> > > > > Thank you for your help.
> > >> > > > >
> > >> > > > > Ho-Chun
> > >> > > > >
> > >> > > > > p.s.
> > >> > > > >
> > >> > > > > regrid_data_plane
> > >> > > > >
> > >> > > > > /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
> > >> > > > > L2-
> > >> > > > > AODC-
> > >> > > > > M6_G16_s20191902301314_e20191902304087_
> > >> > > > > c20191902305575.nc
> > >> > > > > /naqfc/save/Ho-
> > >> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
> > >> > > > >
> > >> > > > > /meso2/noscrub/Ho-
> > >> > > > >
Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
> > >> > > > > 20190709_23_high.nc
> > >> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v
1 -qc
> > >> > > > > 0
> > >> > > > >
> > >> > > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >>
> > >>
> > >>
>
>
>
>
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Fri Jul 19 06:37:51 2019
Hi, Howard,
I think you solve my problem on using [qc=0], [qc=0 + qc=1], and [qc=0
+
qc=1 + qc=2].
I used option -qc 0,1,2 and it seems to include all AOD pixels, some
white-out area in figure LOW is filled in figure ALL that are seen in
figures High or MEDIUM.
Figures below -qc 0 ==> high; -qc 1 ==> medium; -qc 2 ==> low;
-qc=0,1,2
==>all.
Glad to have MET Help to teach us the correct way to perform our
verification. Appreciated.
Ho-Chun
[image: image.png]
[image: image.png]
[image: image.png]
[image: image.png]
On Fri, Jul 19, 2019 at 8:09 AM Ho-Chun Huang - NOAA Affiliate <
ho-chun.huang at noaa.gov> wrote:
> Hi, Howard:
>
> A little bit confuse on *current* regrid_data_plane -qc option. You
said
> with "-*qc 1,2*" is to "*use qc=1 OR qc=2*"? I believe each
satellite
> sensor pixels only have one quality flag value. Am I right that
"*qc=1
> OR qc=2" is to use pixel with EITHER quality flag =1 OR **quality
flag
> =2 ? *Interesting, I will play with it.
>
> If this is correct, then -qc=0,1 is to use AOD (qc=0 and 1) and -qc
0,1,2
> is to use AOD(qc=0, 1, and 2). Then My request can be done in this
way, am
> I correct?
>
> Also, please comment on the use of $MET_TMP_DIR and
> $MET_GEOSTATIONARY_DATA in previous email as I do not know the root
of
> cause of this mapping problem.
>
> Thank you for your help.
>
> Ho-Chun
>
> On Thu, Jul 18, 2019 at 4:45 PM Howard Soh via RT
<met_help at ucar.edu>
> wrote:
>
>> The git issues was created
(https://github.com/NCAR/MET/issues/1168).
>>
>> The -qc argument allows the list of QC values (comma separated,
without
>> space): for example, "-qc 1,2" for QC value 1 or 2.
>> The alternative will be using
>> - "-qc 0"
>> - "-qc 0,1"
>> - "-qc 0,1,2"
>>
>> Cheers,
>> Howard
>>
>> On Thu Jul 18 07:18:36 2019, ho-chun.huang at noaa.gov wrote:
>> > Hi,
>> >
>> > Sorry to send it too early. I want to know in your expert
opinion
>> > that the
>> > usage of $MET_TMP_DIR and $MET_GEOSTATIONARY_DATA will prevent
similar
>> > problem from happening.
>> >
>> > Also, can you clarify current regrid_data_plane with
>> >
>> > -qc 0, is to use ADO with quality flag=0 ONLY
>> > -qc 1, is to use ADO with quality flag=1 ONLY
>> > -qc 2, is to use ADO with quality flag=2 ONLY
>> >
>> > If it is the case, then I think it might have to be changed to
>> >
>> > -qc 0, is to use ADO with quality flag<=0, i.e., quality flag=0.
>> > -qc 1, is to use ADO with quality flag<=1, i.e., quality flag=0
and
>> > quality
>> > flag=1.
>> > -qc 2, is to use ADO with quality flag<=2, i.e., quality flag=0,
1,
>> > and 2
>> > (All AOD)
>> >
>> > We might have to bring John and Tara in for the changes.
>> >
>> > Ho-Chun
>> >
>> > On Thu, Jul 18, 2019 at 9:08 AM Ho-Chun Huang - NOAA Affiliate <
>> > ho-chun.huang at noaa.gov> wrote:
>> >
>> > > Hi, Howard:
>> > >
>> > > I defined the $MET_TMP_DIR and delete everything before I begin
using
>> > > regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA point
to
>> > > the
>> > > location of g16_conus_latlon_2km_20180620.dat. Today's cronjob
seems
>> > > to
>> > > produce a correct G16 AOD mapping.
>> > >
>> > > I am developing this MET verification product targeted for
>> > > operational
>> > > implementation. Thus, this uncertainty of incorrect mapping
can not
>> > > be
>> > > allowed to happen once the verification tool is in NCO's hand.
Could
>> > > you
>> > > elaborate of the reason behind the problem I encountered? and
by
>> > > using
>> > > $MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above will
>> > > eliminate
>> > > the possibility of re-occurrence of this problem. What is
>> > >
>> > > On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT
>> > > <met_help at ucar.edu>
>> > > wrote:
>> > >
>> > >> MET did not give up using the pixel coordinate file (NetCDF or
>> > >> binary
>> > >> file like
>> > >> "g16_conus_latlon_2km_20180620.dat"). The command line
argument "-
>> > >> coord"
>> > >> was removed at V8.1 but the environment variable
>> > >> "MET_GEOSTATIONARY_DATA"
>> > >> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and the
file
>> > >> exists,
>> > >> regrid_data_plane reads the coordinate data file instead of
>> > >> computing.
>> > >>
>> > >> Some users were confused with command line option "-coord"
because
>> > >> "g16_conus_latlon_2km_20180620.dat" was not part of MET and
did not
>> > >> know
>> > >> where to get. So we changed the default behavior to compute
lat/lon.
>> > >>
>> > >> Cheers,
>> > >> Howard
>> > >>
>> > >> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
>> > >> > Hi, Howard:
>> > >> >
>> > >> > When we work on it at the beginning, we do have the pixel
>> > >> > coordinate
>> > >> > file
>> > >> > called "g16_conus_latlon_2km_20180620.dat" that contains the
lat
>> > >> > lon
>> > >> > of
>> > >> > each pixel (fixed in space). I am curious why Metplus gave
up
>> > >> > -coord
>> > >> > option for using g16_conus_latlon_2km_20180620.dat?
Shouldn't
>> > >> > that
>> > >> > give
>> > >> > you exact (lat lon) information?
>> > >> >
>> > >> > However, I bet you must have a good reason to go with
current
>> > >> > option.
>> > >> >
>> > >> > I will test using the $MET_TMP_DIR in my script. Please
wait till
>> > >> > I
>> > >> > can
>> > >> > successfully managing the two temporary files. Thank you.
>> > >> >
>> > >> > Ho-Chun
>> > >> >
>> > >> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
>> > >> > <met_help at ucar.edu>
>> > >> > wrote:
>> > >> >
>> > >> > > The GOES file itself contains information for the spatial
>> > >> > > coordinates
>> > >> > > but
>> > >> > > does not have the lat/lon values. So regrid_data_plane
computes
>> > >> > > the
>> > >> > > lat/lon
>> > >> > > (which took about 1 minute for CONUS) and saves two
temporary
>> > >> > > files
>> > >> > > to skip
>> > >> > > the lat/lon computing next time. They are 1) NetCDF file
with
>> > >> > > lat/lon
>> > >> > > and
>> > >> > > 2) a text file with grid mapping for the target grid. They
are
>> > >> > > saved
>> > >> > > at
>> > >> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
>> > >> > > temporary
>> > >> > > file
>> > >> > > names begin with "CONUS" or "Full" and end with ".nc" or
>> > >> > > ".grid_map".
>> > >> > > If
>> > >> > > the problem is consistent, please find and delete them.
They
>> > >> > > will be
>> > >> > > re-created. If you can not delete them because you are not
>> > >> > > owner,
>> > >> > > please
>> > >> > > set MET_TMP_DIR environment variable to the directory
where you
>> > >> > > can
>> > >> > > write.
>> > >> > > It will be helpful if you send them to me before deleting
them.
>> > >> > >
>> > >> > > Cheers,
>> > >> > > Howard
>> > >> > >
>> > >> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov wrote:
>> > >> > > > To Whom It May Concern:
>> > >> > > >
>> > >> > > > I repeat the regrid_data_plane and plot_data_plane today
and
>> > >> > > > the
>> > >> > > > mapping is
>> > >> > > > back to normal now. I am confused and do not know what
>> > >> > > > happened.
>> > >> > > > Will
>> > >> > > > monitor the cronjob for a few day.
>> > >> > > >
>> > >> > > > Ho-Chun
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via RT
>> > >> > > > <met_help at ucar.edu>
>> > >> > > > wrote:
>> > >> > > >
>> > >> > > > > Greetings,
>> > >> > > > >
>> > >> > > > > This message has been automatically generated in
response to
>> > >> > > > > the
>> > >> > > > > creation
>> > >> > > > > of a trouble ticket regarding:
>> > >> > > > > "",
>> > >> > > > > a summary of which appears below.
>> > >> > > > >
>> > >> > > > > There is no need to reply to this message right now.
Your
>> > >> > > > > ticket
>> > >> > > > > has
>> > >> > > > > been
>> > >> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
>> > >> > > > >
>> > >> > > > > Please include the string:
>> > >> > > > >
>> > >> > > > > [rt.rap.ucar.edu #91097]
>> > >> > > > >
>> > >> > > > > in the subject line of all future correspondence about
this
>> > >> > > > > issue. To
>> > >> > > > > do
>> > >> > > > > so, you may reply to this message.
>> > >> > > > >
>> > >> > > > > For more information, please see:
>> > >> > > > >
>> > >> > > > > MET Online Tutorial:
>> > >> > > > >
>> > >> > >
>>
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
>> > >> > > > >
>> > >> > > > > MET Users Guide:
>> > >> > > > >
https://www.dtcenter.org/met/users/docs/overview.php
>> > >> > > > >
>> > >> > > > > MET FAQs:
>> > >> > > > >
https://www.dtcenter.org/met/users/support/faqs/index.php
>> > >> > > > >
>> > >> > > > > MET-Help Email Archive:
>> > >> > > > > http://mailman.ucar.edu/pipermail/met_help
>> > >> > > > >
>> > >> > > > > Thank you,
>> > >> > > > > met_help at ucar.edu
>> > >> > > > >
>> > >> > > > >
>> > >> > >
>> > >>
>>
-------------------------------------------------------------------------
>> > >> > > > > To Whom It May Concern:
>> > >> > > > >
>> > >> > > > > I first report regrid_data_plane in ticket #90550. It
has
>> > >> > > > > been
>> > >> > > > > resolved
>> > >> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the
ticket
>> > >> > > > > was
>> > >> > > > > closed
>> > >> > > > >
>> > >> > > > > I was able to produce CMAQ mapped G16 AOD till
yesterday.
>> > >> > > > > [image: image.png]
>> > >> > > > >
>> > >> > > > > But today I have problem on the mapped G16 AOD to
CMAQ. The
>> > >> > > > > post
>> > >> > > > > mapped
>> > >> > > > > AOD is not right.
>> > >> > > > > [image: image.png]
>> > >> > > > >
>> > >> > > > > Disregard about the title, they are all using high
quality
>> > >> > > > > AOD.
>> > >> > > > > Note
>> > >> > > > > it is
>> > >> > > > > okay when I mapped to HYSPLIT grid today
>> > >> > > > >
>> > >> > > > > [image: image.png]
>> > >> > > > >
>> > >> > > > > I also repeat the processes on 20190709 and the result
is
>> > >> > > > > the
>> > >> > > > > same.
>> > >> > > > >
>> > >> > > > > Does MET8.1 being changed between yesterday and today?
Can
>> > >> > > > > you
>> > >> > > > > try
>> > >> > > > > based
>> > >> > > > > on the source data and model grid described below (on
Tide).
>> > >> > > > >
>> > >> > > > > Thank you for your help.
>> > >> > > > >
>> > >> > > > > Ho-Chun
>> > >> > > > >
>> > >> > > > > p.s.
>> > >> > > > >
>> > >> > > > > regrid_data_plane
>> > >> > > > >
>> > >> > > > > /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
>> > >> > > > > L2-
>> > >> > > > > AODC-
>> > >> > > > > M6_G16_s20191902301314_e20191902304087_
>> > >> > > > > c20191902305575.nc
>> > >> > > > > /naqfc/save/Ho-
>> > >> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
>> > >> > > > >
>> > >> > > > > /meso2/noscrub/Ho-
>> > >> > > > >
Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
>> > >> > > > > 20190709_23_high.nc
>> > >> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN -v
1 -qc
>> > >> > > > > 0
>> > >> > > > >
>> > >> > > > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >>
>> > >>
>> > >>
>> > >>
>>
>>
>>
>>
------------------------------------------------
Subject:
From: Ho-Chun Huang - NOAA Affiliate
Time: Mon Jul 22 10:57:39 2019
Hi,
The Goes-16 AOD mapping has been done successfully over the weekend.
I
think it is stable with suggestion from Howard. Please close the
ticket.
Ho-Chun
On Fri, Jul 19, 2019 at 8:37 AM Ho-Chun Huang - NOAA Affiliate <
ho-chun.huang at noaa.gov> wrote:
> Hi, Howard,
>
> I think you solve my problem on using [qc=0], [qc=0 + qc=1], and
[qc=0 +
> qc=1 + qc=2].
>
> I used option -qc 0,1,2 and it seems to include all AOD pixels, some
> white-out area in figure LOW is filled in figure ALL that are seen
in
> figures High or MEDIUM.
>
> Figures below -qc 0 ==> high; -qc 1 ==> medium; -qc 2 ==> low;
-qc=0,1,2
> ==>all.
>
> Glad to have MET Help to teach us the correct way to perform our
> verification. Appreciated.
>
> Ho-Chun
>
> [image: image.png]
> [image: image.png]
> [image: image.png]
> [image: image.png]
>
> On Fri, Jul 19, 2019 at 8:09 AM Ho-Chun Huang - NOAA Affiliate <
> ho-chun.huang at noaa.gov> wrote:
>
>> Hi, Howard:
>>
>> A little bit confuse on *current* regrid_data_plane -qc option.
You
>> said with "-*qc 1,2*" is to "*use qc=1 OR qc=2*"? I believe each
>> satellite sensor pixels only have one quality flag value. Am I
right that "*qc=1
>> OR qc=2" is to use pixel with EITHER quality flag =1 OR **quality
flag
>> =2 ? *Interesting, I will play with it.
>>
>> If this is correct, then -qc=0,1 is to use AOD (qc=0 and 1) and -qc
0,1,2
>> is to use AOD(qc=0, 1, and 2). Then My request can be done in this
way, am
>> I correct?
>>
>> Also, please comment on the use of $MET_TMP_DIR and
>> $MET_GEOSTATIONARY_DATA in previous email as I do not know the root
of
>> cause of this mapping problem.
>>
>> Thank you for your help.
>>
>> Ho-Chun
>>
>> On Thu, Jul 18, 2019 at 4:45 PM Howard Soh via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> The git issues was created
(https://github.com/NCAR/MET/issues/1168).
>>>
>>> The -qc argument allows the list of QC values (comma separated,
without
>>> space): for example, "-qc 1,2" for QC value 1 or 2.
>>> The alternative will be using
>>> - "-qc 0"
>>> - "-qc 0,1"
>>> - "-qc 0,1,2"
>>>
>>> Cheers,
>>> Howard
>>>
>>> On Thu Jul 18 07:18:36 2019, ho-chun.huang at noaa.gov wrote:
>>> > Hi,
>>> >
>>> > Sorry to send it too early. I want to know in your expert
opinion
>>> > that the
>>> > usage of $MET_TMP_DIR and $MET_GEOSTATIONARY_DATA will prevent
similar
>>> > problem from happening.
>>> >
>>> > Also, can you clarify current regrid_data_plane with
>>> >
>>> > -qc 0, is to use ADO with quality flag=0 ONLY
>>> > -qc 1, is to use ADO with quality flag=1 ONLY
>>> > -qc 2, is to use ADO with quality flag=2 ONLY
>>> >
>>> > If it is the case, then I think it might have to be changed to
>>> >
>>> > -qc 0, is to use ADO with quality flag<=0, i.e., quality flag=0.
>>> > -qc 1, is to use ADO with quality flag<=1, i.e., quality flag=0
and
>>> > quality
>>> > flag=1.
>>> > -qc 2, is to use ADO with quality flag<=2, i.e., quality flag=0,
1,
>>> > and 2
>>> > (All AOD)
>>> >
>>> > We might have to bring John and Tara in for the changes.
>>> >
>>> > Ho-Chun
>>> >
>>> > On Thu, Jul 18, 2019 at 9:08 AM Ho-Chun Huang - NOAA Affiliate <
>>> > ho-chun.huang at noaa.gov> wrote:
>>> >
>>> > > Hi, Howard:
>>> > >
>>> > > I defined the $MET_TMP_DIR and delete everything before I
begin using
>>> > > regrid_data_plane. I also defined MET_GEOSTATIONARY_DATA
point to
>>> > > the
>>> > > location of g16_conus_latlon_2km_20180620.dat. Today's
cronjob seems
>>> > > to
>>> > > produce a correct G16 AOD mapping.
>>> > >
>>> > > I am developing this MET verification product targeted for
>>> > > operational
>>> > > implementation. Thus, this uncertainty of incorrect mapping
can not
>>> > > be
>>> > > allowed to happen once the verification tool is in NCO's hand.
Could
>>> > > you
>>> > > elaborate of the reason behind the problem I encountered? and
by
>>> > > using
>>> > > $MET_TMP_DIR and MET_GEOSTATIONARY_DATA as described above
will
>>> > > eliminate
>>> > > the possibility of re-occurrence of this problem. What is
>>> > >
>>> > > On Wed, Jul 17, 2019 at 12:42 PM Howard Soh via RT
>>> > > <met_help at ucar.edu>
>>> > > wrote:
>>> > >
>>> > >> MET did not give up using the pixel coordinate file (NetCDF
or
>>> > >> binary
>>> > >> file like
>>> > >> "g16_conus_latlon_2km_20180620.dat"). The command line
argument "-
>>> > >> coord"
>>> > >> was removed at V8.1 but the environment variable
>>> > >> "MET_GEOSTATIONARY_DATA"
>>> > >> was introduced. If "MET_GEOSTATIONARY_DATA" is defined and
the file
>>> > >> exists,
>>> > >> regrid_data_plane reads the coordinate data file instead of
>>> > >> computing.
>>> > >>
>>> > >> Some users were confused with command line option "-coord"
because
>>> > >> "g16_conus_latlon_2km_20180620.dat" was not part of MET and
did not
>>> > >> know
>>> > >> where to get. So we changed the default behavior to compute
lat/lon.
>>> > >>
>>> > >> Cheers,
>>> > >> Howard
>>> > >>
>>> > >> On Wed Jul 17 10:17:04 2019, ho-chun.huang at noaa.gov wrote:
>>> > >> > Hi, Howard:
>>> > >> >
>>> > >> > When we work on it at the beginning, we do have the pixel
>>> > >> > coordinate
>>> > >> > file
>>> > >> > called "g16_conus_latlon_2km_20180620.dat" that contains
the lat
>>> > >> > lon
>>> > >> > of
>>> > >> > each pixel (fixed in space). I am curious why Metplus gave
up
>>> > >> > -coord
>>> > >> > option for using g16_conus_latlon_2km_20180620.dat?
Shouldn't
>>> > >> > that
>>> > >> > give
>>> > >> > you exact (lat lon) information?
>>> > >> >
>>> > >> > However, I bet you must have a good reason to go with
current
>>> > >> > option.
>>> > >> >
>>> > >> > I will test using the $MET_TMP_DIR in my script. Please
wait till
>>> > >> > I
>>> > >> > can
>>> > >> > successfully managing the two temporary files. Thank you.
>>> > >> >
>>> > >> > Ho-Chun
>>> > >> >
>>> > >> > On Wed, Jul 17, 2019 at 11:06 AM Howard Soh via RT
>>> > >> > <met_help at ucar.edu>
>>> > >> > wrote:
>>> > >> >
>>> > >> > > The GOES file itself contains information for the spatial
>>> > >> > > coordinates
>>> > >> > > but
>>> > >> > > does not have the lat/lon values. So regrid_data_plane
computes
>>> > >> > > the
>>> > >> > > lat/lon
>>> > >> > > (which took about 1 minute for CONUS) and saves two
temporary
>>> > >> > > files
>>> > >> > > to skip
>>> > >> > > the lat/lon computing next time. They are 1) NetCDF file
with
>>> > >> > > lat/lon
>>> > >> > > and
>>> > >> > > 2) a text file with grid mapping for the target grid.
They are
>>> > >> > > saved
>>> > >> > > at
>>> > >> > > "/tmp" or at $MET_TMP_DIR if $MET_TMP_DIR is defined. The
>>> > >> > > temporary
>>> > >> > > file
>>> > >> > > names begin with "CONUS" or "Full" and end with ".nc" or
>>> > >> > > ".grid_map".
>>> > >> > > If
>>> > >> > > the problem is consistent, please find and delete them.
They
>>> > >> > > will be
>>> > >> > > re-created. If you can not delete them because you are
not
>>> > >> > > owner,
>>> > >> > > please
>>> > >> > > set MET_TMP_DIR environment variable to the directory
where you
>>> > >> > > can
>>> > >> > > write.
>>> > >> > > It will be helpful if you send them to me before deleting
them.
>>> > >> > >
>>> > >> > > Cheers,
>>> > >> > > Howard
>>> > >> > >
>>> > >> > > On Wed Jul 17 06:07:15 2019, ho-chun.huang at noaa.gov
wrote:
>>> > >> > > > To Whom It May Concern:
>>> > >> > > >
>>> > >> > > > I repeat the regrid_data_plane and plot_data_plane
today and
>>> > >> > > > the
>>> > >> > > > mapping is
>>> > >> > > > back to normal now. I am confused and do not know what
>>> > >> > > > happened.
>>> > >> > > > Will
>>> > >> > > > monitor the cronjob for a few day.
>>> > >> > > >
>>> > >> > > > Ho-Chun
>>> > >> > > >
>>> > >> > > >
>>> > >> > > >
>>> > >> > > > On Tue, Jul 16, 2019 at 3:45 PM met_help at ucar.edu via
RT
>>> > >> > > > <met_help at ucar.edu>
>>> > >> > > > wrote:
>>> > >> > > >
>>> > >> > > > > Greetings,
>>> > >> > > > >
>>> > >> > > > > This message has been automatically generated in
response to
>>> > >> > > > > the
>>> > >> > > > > creation
>>> > >> > > > > of a trouble ticket regarding:
>>> > >> > > > > "",
>>> > >> > > > > a summary of which appears below.
>>> > >> > > > >
>>> > >> > > > > There is no need to reply to this message right now.
Your
>>> > >> > > > > ticket
>>> > >> > > > > has
>>> > >> > > > > been
>>> > >> > > > > assigned an ID of [rt.rap.ucar.edu #91097].
>>> > >> > > > >
>>> > >> > > > > Please include the string:
>>> > >> > > > >
>>> > >> > > > > [rt.rap.ucar.edu #91097]
>>> > >> > > > >
>>> > >> > > > > in the subject line of all future correspondence
about this
>>> > >> > > > > issue. To
>>> > >> > > > > do
>>> > >> > > > > so, you may reply to this message.
>>> > >> > > > >
>>> > >> > > > > For more information, please see:
>>> > >> > > > >
>>> > >> > > > > MET Online Tutorial:
>>> > >> > > > >
>>> > >> > >
>>>
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
>>> > >> > > > >
>>> > >> > > > > MET Users Guide:
>>> > >> > > > >
https://www.dtcenter.org/met/users/docs/overview.php
>>> > >> > > > >
>>> > >> > > > > MET FAQs:
>>> > >> > > > >
>>> https://www.dtcenter.org/met/users/support/faqs/index.php
>>> > >> > > > >
>>> > >> > > > > MET-Help Email Archive:
>>> > >> > > > > http://mailman.ucar.edu/pipermail/met_help
>>> > >> > > > >
>>> > >> > > > > Thank you,
>>> > >> > > > > met_help at ucar.edu
>>> > >> > > > >
>>> > >> > > > >
>>> > >> > >
>>> > >>
>>>
-------------------------------------------------------------------------
>>> > >> > > > > To Whom It May Concern:
>>> > >> > > > >
>>> > >> > > > > I first report regrid_data_plane in ticket #90550.
It has
>>> > >> > > > > been
>>> > >> > > > > resolved
>>> > >> > > > > and I was able to plot CMAQ mapped G16 AOD. Then the
ticket
>>> > >> > > > > was
>>> > >> > > > > closed
>>> > >> > > > >
>>> > >> > > > > I was able to produce CMAQ mapped G16 AOD till
yesterday.
>>> > >> > > > > [image: image.png]
>>> > >> > > > >
>>> > >> > > > > But today I have problem on the mapped G16 AOD to
CMAQ. The
>>> > >> > > > > post
>>> > >> > > > > mapped
>>> > >> > > > > AOD is not right.
>>> > >> > > > > [image: image.png]
>>> > >> > > > >
>>> > >> > > > > Disregard about the title, they are all using high
quality
>>> > >> > > > > AOD.
>>> > >> > > > > Note
>>> > >> > > > > it is
>>> > >> > > > > okay when I mapped to HYSPLIT grid today
>>> > >> > > > >
>>> > >> > > > > [image: image.png]
>>> > >> > > > >
>>> > >> > > > > I also repeat the processes on 20190709 and the
result is
>>> > >> > > > > the
>>> > >> > > > > same.
>>> > >> > > > >
>>> > >> > > > > Does MET8.1 being changed between yesterday and
today? Can
>>> > >> > > > > you
>>> > >> > > > > try
>>> > >> > > > > based
>>> > >> > > > > on the source data and model grid described below (on
Tide).
>>> > >> > > > >
>>> > >> > > > > Thank you for your help.
>>> > >> > > > >
>>> > >> > > > > Ho-Chun
>>> > >> > > > >
>>> > >> > > > > p.s.
>>> > >> > > > >
>>> > >> > > > > regrid_data_plane
>>> > >> > > > >
>>> > >> > > > > /meso2/noscrub/Ho-
Chun.Huang/GOES16_AOD/AOD/20190709/OR_ABI-
>>> > >> > > > > L2-
>>> > >> > > > > AODC-
>>> > >> > > > > M6_G16_s20191902301314_e20191902304087_
>>> > >> > > > > c20191902305575.nc
>>> > >> > > > > /naqfc/save/Ho-
>>> > >> > > > > Chun.Huang/plot/cmaq/parm/aqm.t12z.aot.f15.148.grib2
>>> > >> > > > >
>>> > >> > > > > /meso2/noscrub/Ho-
>>> > >> > > > >
Chun.Huang/GOES16_AOD/REGRID/aqm.20190709/OBS_AOD_aqm_g16_
>>> > >> > > > > 20190709_23_high.nc
>>> > >> > > > > -field 'name="AOD"; level="(*,*)";' -method UW_MEAN
-v 1 -qc
>>> > >> > > > > 0
>>> > >> > > > >
>>> > >> > > > >
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>>
>>>
>>>
>>>
------------------------------------------------
More information about the Met_help
mailing list