[Met_help] [rt.rap.ucar.edu #100067] History for Problem using {CURRENT_FCST_LEVEL} python embedding script
George McCabe via RT
met_help at ucar.edu
Wed Jun 16 15:21:48 MDT 2021
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello metplus support,
I am developing some python embedding scripts for use with METplus-4.0 and MET-10.0.0. Since all my modeling and analysis files are netcdf and level indexing the traditional way is still cumbersome, I pass all the information needed to my read wrapper in order to return a 2D slice as a PYTHON_NUMPY array. So the following is tested and works perfectly in my GridStat_test.conf:
FCST_VAR1_NAME = /gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr H 20191221_2100 20191223_1200 P500
whereby the (1) variable, (2) initial timestamp, (3) valid timestamp, and (4) level are passed to my read script and it returns the appropriate PYTHON_NUMPY array as expected. However, when I try to do the following according to a new feature in https://github.com/dtcenter/METplus/issues/708 :
FCST_VAR1_NAME = /gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M} {CURRENT_FCST_LEVEL}
FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
It fails because the assembled forecast fields looks like this:
FCST_FIELD={ name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py H 20191223_0000 20191223_0000 "; level="P1000"; },{ name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py H 20191223_0000 20191223_0000 "; level="P500"; }
The level info is added to the compound FCST_FIELD object but removed as an argument to my read script, thus it fails. Is there a way I can reference the current level variable/info similar to how {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the metplus documentation somewhere, but I need to change {CURRENT_FCST_LEVEL} to something that will actually print/dump this value for my read script. Any ideas?
Thanks,
Scott
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Problem using {CURRENT_FCST_LEVEL} python embedding script
From: George McCabe
Time: Tue Jun 01 13:13:49 2021
Hi Scott,
Thank you for providing the GitHub issue for this work. I believe this
is
the option you want to use:
https://metplus.readthedocs.io/en/latest/Users_Guide/glossary.html#term-
grid-stat-once-per-field
If you set:
GRID_STAT_ONCE_PER_FIELD = True
then it will call grid_stat once per name/level combination. The
default
approach to building a grid_stat command is to process all of the
fields in
1 call. In this case, the {CURRENT_FCST_LEVEL} isn't set because it is
processing all of them.
If that doesn't work, then the new logic may have broken. Let me know
if
that is the case and I will take a look.
Thanks,
George
On Tue, Jun 1, 2021 at 8:56 AM Rabenhorst, Scott D. (GSFC-
610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> Tue Jun 01 08:56:22 2021: Request 100067 was acted upon.
> Transaction: Ticket created by scott.d.rabenhorst at nasa.gov
> Queue: met_help
> Subject: Problem using {CURRENT_FCST_LEVEL} python embedding
script
> Owner: Nobody
> Requestors: scott.d.rabenhorst at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100067 >
>
>
> Hello metplus support,
>
> I am developing some python embedding scripts for use with METplus-
4.0 and
> MET-10.0.0. Since all my modeling and analysis files are netcdf and
level
> indexing the traditional way is still cumbersome, I pass all the
> information needed to my read wrapper in order to return a 2D slice
as a
> PYTHON_NUMPY array. So the following is tested and works perfectly
in my
> GridStat_test.conf:
>
> FCST_VAR1_NAME =
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> H 20191221_2100 20191223_1200 P500
>
> whereby the (1) variable, (2) initial timestamp, (3) valid
timestamp, and
> (4) level are passed to my read script and it returns the
appropriate
> PYTHON_NUMPY array as expected. However, when I try to do the
following
> according to a new feature in
> https://github.com/dtcenter/METplus/issues/708 :
>
> FCST_VAR1_NAME =
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M}
{CURRENT_FCST_LEVEL}
> FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
>
> It fails because the assembled forecast fields looks like this:
>
> FCST_FIELD={
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> H 20191223_0000 20191223_0000 "; level="P1000"; },{
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> H 20191223_0000 20191223_0000 "; level="P500"; }
>
> The level info is added to the compound FCST_FIELD object but
removed as
> an argument to my read script, thus it fails. Is there a way I can
> reference the current level variable/info similar to how
> {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the metplus
documentation
> somewhere, but I need to change {CURRENT_FCST_LEVEL} to something
that will
> actually print/dump this value for my read script. Any ideas?
>
> Thanks,
> Scott
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #100067] Problem using {CURRENT_FCST_LEVEL} python embedding script
From: Rabenhorst, Scott D. (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC]
Time: Tue Jun 01 13:33:41 2021
Hi George,
Thanks so much for the suggestion. I re-ran metplus setting
"GRID_STAT_ONCE_PER_FIELD = True" and verified it in the
metplus_final.conf file. Unfortunately, the same result happens. The
logfile shows the placeholders "{CURRENT_FCST_LEVEL}" and
"{CURRENT_OBS_LEVEL}" are still dropped from the arguments to my
embedding script and are appended to the *_FIELD objects instead. Is
there anything else I can try?
Thanks,
Scott
On 6/1/21, 3:13 PM, "George McCabe via RT" <met_help at ucar.edu> wrote:
Hi Scott,
Thank you for providing the GitHub issue for this work. I believe
this is
the option you want to use:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmetplus.readthedocs.io%2Fen%2Flatest%2FUsers_Guide%2Fglossary.html%23term-
grid-stat-once-per-
field&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CUzHl5LXMKhG39iq7BjJhbam4D%2B38SmORjAFm4Q%2BH9M%3D&reserved=0
If you set:
GRID_STAT_ONCE_PER_FIELD = True
then it will call grid_stat once per name/level combination. The
default
approach to building a grid_stat command is to process all of the
fields in
1 call. In this case, the {CURRENT_FCST_LEVEL} isn't set because
it is
processing all of them.
If that doesn't work, then the new logic may have broken. Let me
know if
that is the case and I will take a look.
Thanks,
George
On Tue, Jun 1, 2021 at 8:56 AM Rabenhorst, Scott D. (GSFC-
610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> Tue Jun 01 08:56:22 2021: Request 100067 was acted upon.
> Transaction: Ticket created by scott.d.rabenhorst at nasa.gov
> Queue: met_help
> Subject: Problem using {CURRENT_FCST_LEVEL} python
embedding script
> Owner: Nobody
> Requestors: scott.d.rabenhorst at nasa.gov
> Status: new
> Ticket <URL:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kcDkfo6A1p4ij84OImOHz%2FO70FGSQfAcbtn2tE1EBuQ%3D&reserved=0
>
>
>
> Hello metplus support,
>
> I am developing some python embedding scripts for use with
METplus-4.0 and
> MET-10.0.0. Since all my modeling and analysis files are netcdf
and level
> indexing the traditional way is still cumbersome, I pass all the
> information needed to my read wrapper in order to return a 2D
slice as a
> PYTHON_NUMPY array. So the following is tested and works
perfectly in my
> GridStat_test.conf:
>
> FCST_VAR1_NAME =
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> H 20191221_2100 20191223_1200 P500
>
> whereby the (1) variable, (2) initial timestamp, (3) valid
timestamp, and
> (4) level are passed to my read script and it returns the
appropriate
> PYTHON_NUMPY array as expected. However, when I try to do the
following
> according to a new feature in
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdtcenter%2FMETplus%2Fissues%2F708&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ExYydXbpREiyg8m38xX4gOPRbnbW2YDYD1jDTwZ2ewM%3D&reserved=0
:
>
> FCST_VAR1_NAME =
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M}
{CURRENT_FCST_LEVEL}
> FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
>
> It fails because the assembled forecast fields looks like this:
>
> FCST_FIELD={
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> H 20191223_0000 20191223_0000 "; level="P1000"; },{
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> H 20191223_0000 20191223_0000 "; level="P500"; }
>
> The level info is added to the compound FCST_FIELD object but
removed as
> an argument to my read script, thus it fails. Is there a way I
can
> reference the current level variable/info similar to how
> {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the metplus
documentation
> somewhere, but I need to change {CURRENT_FCST_LEVEL} to
something that will
> actually print/dump this value for my read script. Any ideas?
>
> Thanks,
> Scott
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Problem using {CURRENT_FCST_LEVEL} python embedding script
From: George McCabe
Time: Tue Jun 01 14:25:51 2021
Hi Scott,
Sorry, it looks like you should use {fcst_level} instead of
{CURRENT_FCST_LEVEL} and {obs_level} instead of {CURRENT_OBS_LEVEL}.
Let me
know if that doesn't work.
Thanks,
George
On Tue, Jun 1, 2021 at 1:33 PM Rabenhorst, Scott D. (GSFC-
610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100067 >
>
> Hi George,
>
> Thanks so much for the suggestion. I re-ran metplus setting
> "GRID_STAT_ONCE_PER_FIELD = True" and verified it in the
metplus_final.conf
> file. Unfortunately, the same result happens. The logfile shows the
> placeholders "{CURRENT_FCST_LEVEL}" and "{CURRENT_OBS_LEVEL}" are
still
> dropped from the arguments to my embedding script and are appended
to the
> *_FIELD objects instead. Is there anything else I can try?
>
> Thanks,
> Scott
>
>
> On 6/1/21, 3:13 PM, "George McCabe via RT" <met_help at ucar.edu>
wrote:
>
> Hi Scott,
>
> Thank you for providing the GitHub issue for this work. I
believe this
> is
> the option you want to use:
>
>
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmetplus.readthedocs.io%2Fen%2Flatest%2FUsers_Guide%2Fglossary.html%23term-
grid-stat-once-per-
field&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CUzHl5LXMKhG39iq7BjJhbam4D%2B38SmORjAFm4Q%2BH9M%3D&reserved=0
>
> If you set:
>
> GRID_STAT_ONCE_PER_FIELD = True
>
> then it will call grid_stat once per name/level combination. The
> default
> approach to building a grid_stat command is to process all of
the
> fields in
> 1 call. In this case, the {CURRENT_FCST_LEVEL} isn't set because
it is
> processing all of them.
>
> If that doesn't work, then the new logic may have broken. Let me
know
> if
> that is the case and I will take a look.
>
> Thanks,
> George
>
> On Tue, Jun 1, 2021 at 8:56 AM Rabenhorst, Scott D.
> (GSFC-610.1)[SCIENCE
> SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> >
> > Tue Jun 01 08:56:22 2021: Request 100067 was acted upon.
> > Transaction: Ticket created by scott.d.rabenhorst at nasa.gov
> > Queue: met_help
> > Subject: Problem using {CURRENT_FCST_LEVEL} python
embedding
> script
> > Owner: Nobody
> > Requestors: scott.d.rabenhorst at nasa.gov
> > Status: new
> > Ticket <URL:
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kcDkfo6A1p4ij84OImOHz%2FO70FGSQfAcbtn2tE1EBuQ%3D&reserved=0
> >
> >
> >
> > Hello metplus support,
> >
> > I am developing some python embedding scripts for use with
> METplus-4.0 and
> > MET-10.0.0. Since all my modeling and analysis files are
netcdf and
> level
> > indexing the traditional way is still cumbersome, I pass all
the
> > information needed to my read wrapper in order to return a 2D
slice
> as a
> > PYTHON_NUMPY array. So the following is tested and works
perfectly
> in my
> > GridStat_test.conf:
> >
> > FCST_VAR1_NAME =
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > H 20191221_2100 20191223_1200 P500
> >
> > whereby the (1) variable, (2) initial timestamp, (3) valid
> timestamp, and
> > (4) level are passed to my read script and it returns the
appropriate
> > PYTHON_NUMPY array as expected. However, when I try to do the
> following
> > according to a new feature in
> >
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdtcenter%2FMETplus%2Fissues%2F708&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Cb1bb73094de247db50d708d925316681%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581716368125108%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ExYydXbpREiyg8m38xX4gOPRbnbW2YDYD1jDTwZ2ewM%3D&reserved=0
> :
> >
> > FCST_VAR1_NAME =
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M}
{CURRENT_FCST_LEVEL}
> > FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
> >
> > It fails because the assembled forecast fields looks like
this:
> >
> > FCST_FIELD={
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > H 20191223_0000 20191223_0000 "; level="P1000"; },{
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > H 20191223_0000 20191223_0000 "; level="P500"; }
> >
> > The level info is added to the compound FCST_FIELD object but
> removed as
> > an argument to my read script, thus it fails. Is there a way I
can
> > reference the current level variable/info similar to how
> > {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the metplus
> documentation
> > somewhere, but I need to change {CURRENT_FCST_LEVEL} to
something
> that will
> > actually print/dump this value for my read script. Any ideas?
> >
> > Thanks,
> > Scott
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged
> to
> reply to this email outside of your normal working hours.
>
>
>
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #100067] Problem using {CURRENT_FCST_LEVEL} python embedding script
From: Rabenhorst, Scott D. (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC]
Time: Wed Jun 02 08:59:48 2021
Hi George,
Thanks so much. These substitutions work now. I also had to reset
"GRID_STAT_ONCE_PER_FIELD = False" to prevent the same output file
from being overwritten with each new level. However, it all works
great now and this issue is resolved. I am curious if I missed this in
the documentation somewhere? Is there a place I can lookup these
substitution names?
Thanks,
Scott
On 6/1/21, 4:26 PM, "George McCabe via RT" <met_help at ucar.edu> wrote:
Hi Scott,
Sorry, it looks like you should use {fcst_level} instead of
{CURRENT_FCST_LEVEL} and {obs_level} instead of
{CURRENT_OBS_LEVEL}. Let me
know if that doesn't work.
Thanks,
George
On Tue, Jun 1, 2021 at 1:33 PM Rabenhorst, Scott D. (GSFC-
610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> <URL:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZKSMCCWZRmMUGtGdAvA4Xr%2FrSM7Q8z1zON%2Fh7iKQMBk%3D&reserved=0
>
>
> Hi George,
>
> Thanks so much for the suggestion. I re-ran metplus setting
> "GRID_STAT_ONCE_PER_FIELD = True" and verified it in the
metplus_final.conf
> file. Unfortunately, the same result happens. The logfile shows
the
> placeholders "{CURRENT_FCST_LEVEL}" and "{CURRENT_OBS_LEVEL}"
are still
> dropped from the arguments to my embedding script and are
appended to the
> *_FIELD objects instead. Is there anything else I can try?
>
> Thanks,
> Scott
>
>
> On 6/1/21, 3:13 PM, "George McCabe via RT" <met_help at ucar.edu>
wrote:
>
> Hi Scott,
>
> Thank you for providing the GitHub issue for this work. I
believe this
> is
> the option you want to use:
>
>
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmetplus.readthedocs.io%2Fen%2Flatest%2FUsers_Guide%2Fglossary.html%23term-
grid-stat-once-per-
field&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YQZZChgnV6PpEUHO%2FVcC2yk3FmnTs94Gd56%2FqfQraPQ%3D&reserved=0
>
> If you set:
>
> GRID_STAT_ONCE_PER_FIELD = True
>
> then it will call grid_stat once per name/level combination.
The
> default
> approach to building a grid_stat command is to process all
of the
> fields in
> 1 call. In this case, the {CURRENT_FCST_LEVEL} isn't set
because it is
> processing all of them.
>
> If that doesn't work, then the new logic may have broken.
Let me know
> if
> that is the case and I will take a look.
>
> Thanks,
> George
>
> On Tue, Jun 1, 2021 at 8:56 AM Rabenhorst, Scott D.
> (GSFC-610.1)[SCIENCE
> SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu>
wrote:
>
> >
> > Tue Jun 01 08:56:22 2021: Request 100067 was acted upon.
> > Transaction: Ticket created by scott.d.rabenhorst at nasa.gov
> > Queue: met_help
> > Subject: Problem using {CURRENT_FCST_LEVEL} python
embedding
> script
> > Owner: Nobody
> > Requestors: scott.d.rabenhorst at nasa.gov
> > Status: new
> > Ticket <URL:
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZKSMCCWZRmMUGtGdAvA4Xr%2FrSM7Q8z1zON%2Fh7iKQMBk%3D&reserved=0
> >
> >
> >
> > Hello metplus support,
> >
> > I am developing some python embedding scripts for use with
> METplus-4.0 and
> > MET-10.0.0. Since all my modeling and analysis files are
netcdf and
> level
> > indexing the traditional way is still cumbersome, I pass
all the
> > information needed to my read wrapper in order to return a
2D slice
> as a
> > PYTHON_NUMPY array. So the following is tested and works
perfectly
> in my
> > GridStat_test.conf:
> >
> > FCST_VAR1_NAME =
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > H 20191221_2100 20191223_1200 P500
> >
> > whereby the (1) variable, (2) initial timestamp, (3) valid
> timestamp, and
> > (4) level are passed to my read script and it returns the
appropriate
> > PYTHON_NUMPY array as expected. However, when I try to do
the
> following
> > according to a new feature in
> >
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdtcenter%2FMETplus%2Fissues%2F708&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RwUBCsaME8vm9cIHeW%2F%2F8eBZGklyytcG99XhAhpfEJI%3D&reserved=0
> :
> >
> > FCST_VAR1_NAME =
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M}
{CURRENT_FCST_LEVEL}
> > FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
> >
> > It fails because the assembled forecast fields looks like
this:
> >
> > FCST_FIELD={
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > H 20191223_0000 20191223_0000 "; level="P1000"; },{
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > H 20191223_0000 20191223_0000 "; level="P500"; }
> >
> > The level info is added to the compound FCST_FIELD object
but
> removed as
> > an argument to my read script, thus it fails. Is there a
way I can
> > reference the current level variable/info similar to how
> > {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the
metplus
> documentation
> > somewhere, but I need to change {CURRENT_FCST_LEVEL} to
something
> that will
> > actually print/dump this value for my read script. Any
ideas?
> >
> > Thanks,
> > Scott
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not
feel obliged
> to
> reply to this email outside of your normal working hours.
>
>
>
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Problem using {CURRENT_FCST_LEVEL} python embedding script
From: George McCabe
Time: Wed Jun 02 09:31:52 2021
Hi Scott,
I forgot to mention that you will have to format the output templates
so
that different files are written for each field. It sounds like you
figured
that part out.
It looks like the documentation does not mention that you can use
{fcst_level} and {obs_level} in the [FCST/OBS]_VAR<n>_NAME variable.
Based
on the GitHub issue for this work it looks like I implemented the
change
with another task but did not list which pull request included the
changes.
We have since refined our workflow process to ensure that new
functionality
is documented when it is added. The new content should go into this
section:
https://metplus.readthedocs.io/en/latest/Users_Guide/systemconfiguration.html#field-
info
I created a GitHub issue to properly document this functionality:
https://github.com/dtcenter/METplus/issues/943
Thanks for bringing this to my attention!
- George
On Wed, Jun 2, 2021 at 9:00 AM Rabenhorst, Scott D. (GSFC-
610.1)[SCIENCE
SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100067 >
>
> Hi George,
>
> Thanks so much. These substitutions work now. I also had to reset
> "GRID_STAT_ONCE_PER_FIELD = False" to prevent the same output file
from
> being overwritten with each new level. However, it all works great
now and
> this issue is resolved. I am curious if I missed this in the
documentation
> somewhere? Is there a place I can lookup these substitution names?
>
> Thanks,
> Scott
>
>
> On 6/1/21, 4:26 PM, "George McCabe via RT" <met_help at ucar.edu>
wrote:
>
> Hi Scott,
>
> Sorry, it looks like you should use {fcst_level} instead of
> {CURRENT_FCST_LEVEL} and {obs_level} instead of
{CURRENT_OBS_LEVEL}.
> Let me
> know if that doesn't work.
>
> Thanks,
> George
>
> On Tue, Jun 1, 2021 at 1:33 PM Rabenhorst, Scott D.
> (GSFC-610.1)[SCIENCE
> SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu> wrote:
>
> >
> > <URL:
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZKSMCCWZRmMUGtGdAvA4Xr%2FrSM7Q8z1zON%2Fh7iKQMBk%3D&reserved=0
> >
> >
> > Hi George,
> >
> > Thanks so much for the suggestion. I re-ran metplus setting
> > "GRID_STAT_ONCE_PER_FIELD = True" and verified it in the
> metplus_final.conf
> > file. Unfortunately, the same result happens. The logfile
shows the
> > placeholders "{CURRENT_FCST_LEVEL}" and "{CURRENT_OBS_LEVEL}"
are
> still
> > dropped from the arguments to my embedding script and are
appended
> to the
> > *_FIELD objects instead. Is there anything else I can try?
> >
> > Thanks,
> > Scott
> >
> >
> > On 6/1/21, 3:13 PM, "George McCabe via RT" <met_help at ucar.edu>
> wrote:
> >
> > Hi Scott,
> >
> > Thank you for providing the GitHub issue for this work. I
> believe this
> > is
> > the option you want to use:
> >
> >
> >
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmetplus.readthedocs.io%2Fen%2Flatest%2FUsers_Guide%2Fglossary.html%23term-
grid-stat-once-per-
field&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YQZZChgnV6PpEUHO%2FVcC2yk3FmnTs94Gd56%2FqfQraPQ%3D&reserved=0
> >
> > If you set:
> >
> > GRID_STAT_ONCE_PER_FIELD = True
> >
> > then it will call grid_stat once per name/level
combination. The
> > default
> > approach to building a grid_stat command is to process all
of the
> > fields in
> > 1 call. In this case, the {CURRENT_FCST_LEVEL} isn't set
because
> it is
> > processing all of them.
> >
> > If that doesn't work, then the new logic may have broken.
Let me
> know
> > if
> > that is the case and I will take a look.
> >
> > Thanks,
> > George
> >
> > On Tue, Jun 1, 2021 at 8:56 AM Rabenhorst, Scott D.
> > (GSFC-610.1)[SCIENCE
> > SYSTEMS AND APPLICATIONS INC] via RT <met_help at ucar.edu>
wrote:
> >
> > >
> > > Tue Jun 01 08:56:22 2021: Request 100067 was acted upon.
> > > Transaction: Ticket created by
scott.d.rabenhorst at nasa.gov
> > > Queue: met_help
> > > Subject: Problem using {CURRENT_FCST_LEVEL} python
> embedding
> > script
> > > Owner: Nobody
> > > Requestors: scott.d.rabenhorst at nasa.gov
> > > Status: new
> > > Ticket <URL:
> >
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D100067&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZKSMCCWZRmMUGtGdAvA4Xr%2FrSM7Q8z1zON%2Fh7iKQMBk%3D&reserved=0
> > >
> > >
> > >
> > > Hello metplus support,
> > >
> > > I am developing some python embedding scripts for use
with
> > METplus-4.0 and
> > > MET-10.0.0. Since all my modeling and analysis files are
> netcdf and
> > level
> > > indexing the traditional way is still cumbersome, I pass
all
> the
> > > information needed to my read wrapper in order to return
a 2D
> slice
> > as a
> > > PYTHON_NUMPY array. So the following is tested and works
> perfectly
> > in my
> > > GridStat_test.conf:
> > >
> > > FCST_VAR1_NAME =
> > >
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > > H 20191221_2100 20191223_1200 P500
> > >
> > > whereby the (1) variable, (2) initial timestamp, (3)
valid
> > timestamp, and
> > > (4) level are passed to my read script and it returns
the
> appropriate
> > > PYTHON_NUMPY array as expected. However, when I try to
do the
> > following
> > > according to a new feature in
> > >
> >
>
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdtcenter%2FMETplus%2Fissues%2F708&data=04%7C01%7Cscott.d.rabenhorst%40nasa.gov%7Ceb53fc1b9e3e437fdbda08d9253b7804%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637581759611791914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RwUBCsaME8vm9cIHeW%2F%2F8eBZGklyytcG99XhAhpfEJI%3D&reserved=0
> > :
> > >
> > > FCST_VAR1_NAME =
> > >
> >
>
/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr
> > > H {init?fmt=%Y%m%d_%H%M} {valid?fmt=%Y%m%d_%H%M}
> {CURRENT_FCST_LEVEL}
> > > FCST_VAR1_LEVELS = P1000,P850,P700,P500,P250,P100
> > >
> > > It fails because the assembled forecast fields looks
like this:
> > >
> > > FCST_FIELD={
> > >
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > > H 20191223_0000 20191223_0000 "; level="P1000"; },{
> > >
> >
>
name="/gpfsm/dnb78s1/projects/p18/sdrabenh/validation_data/metplus_testing_v2/scripts/read_g5fcst2xr.py
> > > H 20191223_0000 20191223_0000 "; level="P500"; }
> > >
> > > The level info is added to the compound FCST_FIELD
object but
> > removed as
> > > an argument to my read script, thus it fails. Is there a
way I
> can
> > > reference the current level variable/info similar to how
> > > {valid?fmt=%Y%m%d_%H%M} works? Perhaps this is in the
metplus
> > documentation
> > > somewhere, but I need to change {CURRENT_FCST_LEVEL} to
> something
> > that will
> > > actually print/dump this value for my read script. Any
ideas?
> > >
> > > Thanks,
> > > Scott
> > >
> > >
> >
> > --
> > George McCabe - Software Engineer III
> > National Center for Atmospheric Research
> > Research Applications Laboratory
> > 303-497-2768
> > ---
> > My working day may not be your working day. Please do not
feel
> obliged
> > to
> > reply to this email outside of your normal working hours.
> >
> >
> >
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged
> to
> reply to this email outside of your normal working hours.
>
>
>
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
More information about the Met_help
mailing list