[Met_help] [rt.rap.ucar.edu #100271] History for indexing multiple dimensions of GRIB input
Minna Win via RT
met_help at ucar.edu
Tue Jun 22 11:01:05 MDT 2021
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I have a question about configuring forecast field levels for particular
GridStat use cases. The task is to generate continuous statistics and I'd
like to specify the input levels of the forecast field, which I have stored
as a GRIB file, but I'm having problems using the conventional "P850"
values as recommended in the online documentation.
The input data have four dimensions: step (1 month, 2 month, 3 month ...),
isobaric hPa level (1000, 500, ...), lats and lons. When I specify the
pressure level (e.g., level="P850") MET finds several matching fields, each
a different lead time, or "step," and incorrectly chooses the first field.
As an alternative, I'd like to specify the field by indexing the step and
pressure level dimensions [e.g., "(0,0,*,*)"], but to do that, it seems
that I need to be using netCDF instead. Is there a similar method for
specifying multiple dimensions if the input I'm using is a GRIB file?
I can provide more information about the relevant input data, logs, or
config files if needed.
Best,
-Marcel
--
*___________________________________*
*Marcel G. Caron*
Physical Scientist, I.M. Systems Group, Inc.
Affiliate, Model Evaluation Group
@NOAA/NWS/NCEP/EMC
*5830 University Research Court,*
*College Park, MD 20740*
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: indexing multiple dimensions of GRIB input
From: Minna Win
Time: Thu Jun 17 16:29:19 2021
Hi Marcel,
It looks like your grid-stat output isn't what you were expecting. I
don't
think you need netCDF input to accomplish what you are trying to do,
the
grid-stat tool accepts gridded input. I'll need to find someone who
has
more first-hand experience with setting up grid-stat.
Regards,
Minna
---------------
Minna Win
Pronouns: she/her
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
---------------
On Thu, Jun 17, 2021 at 3:48 PM Marcel Caron - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:
>
> Thu Jun 17 15:48:14 2021: Request 100271 was acted upon.
> Transaction: Ticket created by marcel.caron at noaa.gov
> Queue: met_help
> Subject: indexing multiple dimensions of GRIB input
> Owner: Nobody
> Requestors: marcel.caron at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271 >
>
>
> Hi,
>
> I have a question about configuring forecast field levels for
particular
> GridStat use cases. The task is to generate continuous statistics
and I'd
> like to specify the input levels of the forecast field, which I have
stored
> as a GRIB file, but I'm having problems using the conventional
"P850"
> values as recommended in the online documentation.
>
> The input data have four dimensions: step (1 month, 2 month, 3 month
...),
> isobaric hPa level (1000, 500, ...), lats and lons. When I specify
the
> pressure level (e.g., level="P850") MET finds several matching
fields, each
> a different lead time, or "step," and incorrectly chooses the first
field.
> As an alternative, I'd like to specify the field by indexing the
step and
> pressure level dimensions [e.g., "(0,0,*,*)"], but to do that, it
seems
> that I need to be using netCDF instead. Is there a similar method
for
> specifying multiple dimensions if the input I'm using is a GRIB
file?
>
> I can provide more information about the relevant input data, logs,
or
> config files if needed.
>
> Best,
> -Marcel
>
> --
> *___________________________________*
> *Marcel G. Caron*
> Physical Scientist, I.M. Systems Group, Inc.
> Affiliate, Model Evaluation Group
> @NOAA/NWS/NCEP/EMC
> *5830 University Research Court,*
> *College Park, MD 20740*
>
>
------------------------------------------------
Subject: indexing multiple dimensions of GRIB input
From: Minna Win
Time: Fri Jun 18 09:11:16 2021
Hi Marcel,
Here is some additional information for specifying levels for grib
data:
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html
and search for "GRIB_lvl_typ".
I hope that helps.
Regards,
Minna
---------------
Minna Win
Pronouns: she/her
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
---------------
On Thu, Jun 17, 2021 at 3:48 PM Marcel Caron - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:
>
> Thu Jun 17 15:48:14 2021: Request 100271 was acted upon.
> Transaction: Ticket created by marcel.caron at noaa.gov
> Queue: met_help
> Subject: indexing multiple dimensions of GRIB input
> Owner: Nobody
> Requestors: marcel.caron at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271 >
>
>
> Hi,
>
> I have a question about configuring forecast field levels for
particular
> GridStat use cases. The task is to generate continuous statistics
and I'd
> like to specify the input levels of the forecast field, which I have
stored
> as a GRIB file, but I'm having problems using the conventional
"P850"
> values as recommended in the online documentation.
>
> The input data have four dimensions: step (1 month, 2 month, 3 month
...),
> isobaric hPa level (1000, 500, ...), lats and lons. When I specify
the
> pressure level (e.g., level="P850") MET finds several matching
fields, each
> a different lead time, or "step," and incorrectly chooses the first
field.
> As an alternative, I'd like to specify the field by indexing the
step and
> pressure level dimensions [e.g., "(0,0,*,*)"], but to do that, it
seems
> that I need to be using netCDF instead. Is there a similar method
for
> specifying multiple dimensions if the input I'm using is a GRIB
file?
>
> I can provide more information about the relevant input data, logs,
or
> config files if needed.
>
> Best,
> -Marcel
>
> --
> *___________________________________*
> *Marcel G. Caron*
> Physical Scientist, I.M. Systems Group, Inc.
> Affiliate, Model Evaluation Group
> @NOAA/NWS/NCEP/EMC
> *5830 University Research Court,*
> *College Park, MD 20740*
>
>
------------------------------------------------
Subject: indexing multiple dimensions of GRIB input
From: Marcel Caron - NOAA Affiliate
Time: Fri Jun 18 16:22:53 2021
Minna:
Thank you for the reference. I think the following quote from the
website
you linked may be what I was looking for:
*"The 'lead_time' entry specifies the lead time in HH[MMSS] format.
This
entry can be included in the 'fcst' entry as shown below or included
in the
'field' entry if the user would like to use different lead times for
different fields.*
*...*
*"It is only necessary to use the “init_time”, “valid_time”, and/or
“lead_time” settings when verifying a file containing data for
multiple
output times. For example, to verify a GRIB file containing data for
many
lead times, you could use “lead_time” to specify the record to be
verified." *
I'm off for the weekend but will update this thread shortly after
setting
the "lead_time" entry and running the use case again.
Thanks,
-Marcel
On Fri, Jun 18, 2021 at 11:11 AM Minna Win via RT <met_help at ucar.edu>
wrote:
> Hi Marcel,
>
> Here is some additional information for specifying levels for grib
data:
>
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html
>
> and search for "GRIB_lvl_typ".
>
> I hope that helps.
>
> Regards,
> Minna
> ---------------
> Minna Win
> Pronouns: she/her
> National Center for Atmospheric Research
> Developmental Testbed Center
> Phone: 303-497-8423
> Fax: 303-497-8401
> ---------------
>
>
>
> On Thu, Jun 17, 2021 at 3:48 PM Marcel Caron - NOAA Affiliate via RT
<
> met_help at ucar.edu> wrote:
>
> >
> > Thu Jun 17 15:48:14 2021: Request 100271 was acted upon.
> > Transaction: Ticket created by marcel.caron at noaa.gov
> > Queue: met_help
> > Subject: indexing multiple dimensions of GRIB input
> > Owner: Nobody
> > Requestors: marcel.caron at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271 >
> >
> >
> > Hi,
> >
> > I have a question about configuring forecast field levels for
particular
> > GridStat use cases. The task is to generate continuous statistics
and
> I'd
> > like to specify the input levels of the forecast field, which I
have
> stored
> > as a GRIB file, but I'm having problems using the conventional
"P850"
> > values as recommended in the online documentation.
> >
> > The input data have four dimensions: step (1 month, 2 month, 3
month
> ...),
> > isobaric hPa level (1000, 500, ...), lats and lons. When I
specify the
> > pressure level (e.g., level="P850") MET finds several matching
fields,
> each
> > a different lead time, or "step," and incorrectly chooses the
first
> field.
> > As an alternative, I'd like to specify the field by indexing the
step and
> > pressure level dimensions [e.g., "(0,0,*,*)"], but to do that, it
seems
> > that I need to be using netCDF instead. Is there a similar method
for
> > specifying multiple dimensions if the input I'm using is a GRIB
file?
> >
> > I can provide more information about the relevant input data,
logs, or
> > config files if needed.
> >
> > Best,
> > -Marcel
> >
> > --
> > *___________________________________*
> > *Marcel G. Caron*
> > Physical Scientist, I.M. Systems Group, Inc.
> > Affiliate, Model Evaluation Group
> > @NOAA/NWS/NCEP/EMC
> > *5830 University Research Court,*
> > *College Park, MD 20740*
> >
> >
>
>
------------------------------------------------
Subject: indexing multiple dimensions of GRIB input
From: Marcel Caron - NOAA Affiliate
Time: Tue Jun 22 07:19:12 2021
Minna:
I managed to work around the issue using the "lead_time" setting in
the MET
forecast dictionary as mentioned above. Just to update this thread,
here
is the forecast dictionary in my GridStat file:
fcst = {
lead_time = "${FCST_HOUR_END}";
field = [ ${FCST_FIELD} ];
}
The FCST_HOUR_END is a user-defined variable under [user_env_vars] in
the
METplus config file. With this setting, MET/METplus is pulling the
correct
variables from my GRIB files.
Thanks again,
-Marcel
On Fri, Jun 18, 2021 at 6:22 PM Marcel Caron - NOAA Affiliate <
marcel.caron at noaa.gov> wrote:
> Minna:
>
> Thank you for the reference. I think the following quote from the
website
> you linked may be what I was looking for:
>
>
> *"The 'lead_time' entry specifies the lead time in HH[MMSS] format.
This
> entry can be included in the 'fcst' entry as shown below or included
in the
> 'field' entry if the user would like to use different lead times for
> different fields.*
> *...*
> *"It is only necessary to use the “init_time”, “valid_time”, and/or
> “lead_time” settings when verifying a file containing data for
multiple
> output times. For example, to verify a GRIB file containing data for
many
> lead times, you could use “lead_time” to specify the record to be
> verified." *
>
> I'm off for the weekend but will update this thread shortly after
setting
> the "lead_time" entry and running the use case again.
>
> Thanks,
> -Marcel
>
> On Fri, Jun 18, 2021 at 11:11 AM Minna Win via RT
<met_help at ucar.edu>
> wrote:
>
>> Hi Marcel,
>>
>> Here is some additional information for specifying levels for grib
data:
>>
>>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html
>>
>> and search for "GRIB_lvl_typ".
>>
>> I hope that helps.
>>
>> Regards,
>> Minna
>> ---------------
>> Minna Win
>> Pronouns: she/her
>> National Center for Atmospheric Research
>> Developmental Testbed Center
>> Phone: 303-497-8423
>> Fax: 303-497-8401
>> ---------------
>>
>>
>>
>> On Thu, Jun 17, 2021 at 3:48 PM Marcel Caron - NOAA Affiliate via
RT <
>> met_help at ucar.edu> wrote:
>>
>> >
>> > Thu Jun 17 15:48:14 2021: Request 100271 was acted upon.
>> > Transaction: Ticket created by marcel.caron at noaa.gov
>> > Queue: met_help
>> > Subject: indexing multiple dimensions of GRIB input
>> > Owner: Nobody
>> > Requestors: marcel.caron at noaa.gov
>> > Status: new
>> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271
>> >
>> >
>> >
>> > Hi,
>> >
>> > I have a question about configuring forecast field levels for
particular
>> > GridStat use cases. The task is to generate continuous
statistics and
>> I'd
>> > like to specify the input levels of the forecast field, which I
have
>> stored
>> > as a GRIB file, but I'm having problems using the conventional
"P850"
>> > values as recommended in the online documentation.
>> >
>> > The input data have four dimensions: step (1 month, 2 month, 3
month
>> ...),
>> > isobaric hPa level (1000, 500, ...), lats and lons. When I
specify the
>> > pressure level (e.g., level="P850") MET finds several matching
fields,
>> each
>> > a different lead time, or "step," and incorrectly chooses the
first
>> field.
>> > As an alternative, I'd like to specify the field by indexing the
step
>> and
>> > pressure level dimensions [e.g., "(0,0,*,*)"], but to do that, it
seems
>> > that I need to be using netCDF instead. Is there a similar
method for
>> > specifying multiple dimensions if the input I'm using is a GRIB
file?
>> >
>> > I can provide more information about the relevant input data,
logs, or
>> > config files if needed.
>> >
>> > Best,
>> > -Marcel
>> >
>> > --
>> > *___________________________________*
>> > *Marcel G. Caron*
>> > Physical Scientist, I.M. Systems Group, Inc.
>> > Affiliate, Model Evaluation Group
>> > @NOAA/NWS/NCEP/EMC
>> > *5830 University Research Court,*
>> > *College Park, MD 20740*
>> >
>> >
>>
>>
------------------------------------------------
Subject: indexing multiple dimensions of GRIB input
From: Minna Win
Time: Tue Jun 22 08:51:01 2021
Hi Marcel,
I'm glad to hear things are working. Thanks for the update.
Regards,
Minna
---------------
Minna Win
Pronouns: she/her
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
---------------
On Tue, Jun 22, 2021 at 7:19 AM Marcel Caron - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271 >
>
> Minna:
>
> I managed to work around the issue using the "lead_time" setting in
the MET
> forecast dictionary as mentioned above. Just to update this thread,
here
> is the forecast dictionary in my GridStat file:
>
> fcst = {
> lead_time = "${FCST_HOUR_END}";
> field = [ ${FCST_FIELD} ];
> }
>
> The FCST_HOUR_END is a user-defined variable under [user_env_vars]
in the
> METplus config file. With this setting, MET/METplus is pulling the
correct
> variables from my GRIB files.
>
> Thanks again,
> -Marcel
>
> On Fri, Jun 18, 2021 at 6:22 PM Marcel Caron - NOAA Affiliate <
> marcel.caron at noaa.gov> wrote:
>
> > Minna:
> >
> > Thank you for the reference. I think the following quote from the
> website
> > you linked may be what I was looking for:
> >
> >
> > *"The 'lead_time' entry specifies the lead time in HH[MMSS]
format. This
> > entry can be included in the 'fcst' entry as shown below or
included in
> the
> > 'field' entry if the user would like to use different lead times
for
> > different fields.*
> > *...*
> > *"It is only necessary to use the “init_time”, “valid_time”,
and/or
> > “lead_time” settings when verifying a file containing data for
multiple
> > output times. For example, to verify a GRIB file containing data
for many
> > lead times, you could use “lead_time” to specify the record to be
> > verified." *
> >
> > I'm off for the weekend but will update this thread shortly after
setting
> > the "lead_time" entry and running the use case again.
> >
> > Thanks,
> > -Marcel
> >
> > On Fri, Jun 18, 2021 at 11:11 AM Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> Hi Marcel,
> >>
> >> Here is some additional information for specifying levels for
grib data:
> >>
> >>
> https://met.readthedocs.io/en/latest/Users_Guide/config_options.html
> >>
> >> and search for "GRIB_lvl_typ".
> >>
> >> I hope that helps.
> >>
> >> Regards,
> >> Minna
> >> ---------------
> >> Minna Win
> >> Pronouns: she/her
> >> National Center for Atmospheric Research
> >> Developmental Testbed Center
> >> Phone: 303-497-8423
> >> Fax: 303-497-8401
> >> ---------------
> >>
> >>
> >>
> >> On Thu, Jun 17, 2021 at 3:48 PM Marcel Caron - NOAA Affiliate via
RT <
> >> met_help at ucar.edu> wrote:
> >>
> >> >
> >> > Thu Jun 17 15:48:14 2021: Request 100271 was acted upon.
> >> > Transaction: Ticket created by marcel.caron at noaa.gov
> >> > Queue: met_help
> >> > Subject: indexing multiple dimensions of GRIB input
> >> > Owner: Nobody
> >> > Requestors: marcel.caron at noaa.gov
> >> > Status: new
> >> > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100271
> >> >
> >> >
> >> >
> >> > Hi,
> >> >
> >> > I have a question about configuring forecast field levels for
> particular
> >> > GridStat use cases. The task is to generate continuous
statistics and
> >> I'd
> >> > like to specify the input levels of the forecast field, which I
have
> >> stored
> >> > as a GRIB file, but I'm having problems using the conventional
"P850"
> >> > values as recommended in the online documentation.
> >> >
> >> > The input data have four dimensions: step (1 month, 2 month, 3
month
> >> ...),
> >> > isobaric hPa level (1000, 500, ...), lats and lons. When I
specify
> the
> >> > pressure level (e.g., level="P850") MET finds several matching
fields,
> >> each
> >> > a different lead time, or "step," and incorrectly chooses the
first
> >> field.
> >> > As an alternative, I'd like to specify the field by indexing
the step
> >> and
> >> > pressure level dimensions [e.g., "(0,0,*,*)"], but to do that,
it
> seems
> >> > that I need to be using netCDF instead. Is there a similar
method for
> >> > specifying multiple dimensions if the input I'm using is a GRIB
file?
> >> >
> >> > I can provide more information about the relevant input data,
logs, or
> >> > config files if needed.
> >> >
> >> > Best,
> >> > -Marcel
> >> >
> >> > --
> >> > *___________________________________*
> >> > *Marcel G. Caron*
> >> > Physical Scientist, I.M. Systems Group, Inc.
> >> > Affiliate, Model Evaluation Group
> >> > @NOAA/NWS/NCEP/EMC
> >> > *5830 University Research Court,*
> >> > *College Park, MD 20740*
> >> >
> >> >
> >>
> >>
>
>
------------------------------------------------
More information about the Met_help
mailing list