[Met_help] [rt.rap.ucar.edu #91919] History for METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
George McCabe via RT
met_help at ucar.edu
Wed Oct 2 08:29:29 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello. I have a question about the two levels of config files used in
METplus (let's say configs for GridStat), for a run like this:
master_metplus.py \
-c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
-c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
The first config file in question is fv3sar_24h.conf, and the second
config is the GRID_STAT_CONFIG_FILE specified in (when(model=fv3sar)
fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see attached).
I'd like to run the above for a number of models, all with the same
thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like to have
the set up in common among all the models (for the 24h CTC and SL1L2
verif) in the GRID_STAT_CONFIG_FILE, and to have ${mode}l_24h.conf
containing just the model-specific info, like FCST_PCP_COMBINE_METHOD,
FCST_VAR1_NAME (in case there's an int'l model that uses an odd,
non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably run a
separate job to do PcpCombine and RegridDataPlane for the analysis,
before running master_metplus.py for model verif (initially I thought
I'd run the PcpCombine/RegridDataPlane for the analysis with
verification on the first model being verified, but it seems cleaner to
separate out the PcpCombine/RegridDataPlane for the analysis, in case we
need to turn verif for any specific model on/off temporarily). Questions
(I mean in below whether things can be done under the current METplus,
not whether it can be made possible in a future METplus):
1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If so,
where/how to do that?
2. I tried listing all the poly files for the verifying regions in
"poly" under "mask = { }" and it does work (see attached
GridStatConfig_ctc_sl1l2). I specified the fulll path to each poly
.nc file because I couldn't figure out how to pass the mask
directory to this config file. I tried "export
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
in the calling script and "polydir = "${CONUS14}";" in the
GRID_STAT_CONFIG_FILE (see attached
GridStatConfig_ctc_sl1l2.poly.notwork), also added "CONUS14 =
{ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export" to
GRID_STAT_CONFIG_FILE is somehow done through the fv3sar_24h.conf.
It didn't work. How to export such a path name to
GRID_STAT_CONFIG_FILE from the run script?
3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf to the
GRID_STAT_CONFIG_FILE, that way if something needs to be changed for
all models it can be done just once in GRID_STAT_CONFIG_FILE?
Thanks!
Ying
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
From: George McCabe
Time: Thu Sep 05 12:53:32 2019
Hi Ying,
1) Yes. When you set FCST_VAR1_THRESH, it will automatically be added
to
the file specified by GRID_STAT_CONFIG_FILE. Look at the logs when you
run
METplus, and you will see that the environment variable FCST_FIELD
contains
the correct notation to specify the threshold values that you
specified in
FCST_VAR1_THRESH. Here is an example:
In parm/use_cases/qpf/examples/ruc-vs-s2grib.conf, we have:
FCST_VAR1_NAME = APCP
FCST_VAR1_LEVELS = A03
FCST_VAR1_THRESH = gt12.7, gt25.4, gt50.8, gt76.2
And in the log file from METplus:
08/30 17:05:24.930 metplus.GridStat (command_builder.py:135) DEBUG:
FCST_FIELD={ name="APCP"; level="A03"; cat_thresh=[
gt12.7,gt25.4,gt50.8,gt76.2 ]; }
08/30 17:05:24.930 metplus.GridStat (command_builder.py:135) DEBUG:
OBS_FIELD={ name="APCP_03"; level="(*,*)"; cat_thresh=[
gt12.7,gt25.4,gt50.8,gt76.2 ]; }
Generally the OBS_FIELD will be populated with the same values as
FCST_* if
you don't specify OBS_*, but in this case, PcpCombine is run on the
observation data prior to GridStat, so METplus formats this field
information with that in mind.
2) To accomplish what you are trying to do, you don't need to create a
variable called polydir inside the GridStat config file. Instead, you
should name the environment variable polydir. Then you can reference
that
environment variable directly.
In your environment:
export
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
and in GridStat config:
mask = {
grid = ["FULL"];
poly = [ "${polydir}/CONUS.nc", "${polydir}/APL.nc",
"${polydir}/GMC.nc", "${polydir}/GRB.nc", "${polydir}/LMV.nc",
"${polydir}/MDW.nc", "${polydir}/NEC.nc", "${polydir}/NMT.nc",
"${polydir}/NPL.nc", "${polydir}/NWC.nc", "${polydir}/SEC.nc",
"${polydir}/SMT.nc", "${polydir}/SPL.nc", "${polydir}/SWC.nc",
"${polydir}/SWD.nc"];
}
This should work just fine. I am not sure how to reference other
variables
with a MET (GridStat) config file, but there may be a way to do it,
but it
is not necessary for this example.
Another way to set the environment variable polydir is to add an item
to
your model.conf file like this:
[user_env_vars]
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
This will create an environment variable called polydir and set it
only for
your METplus runs, so it can be accessed by the GridStat config file.
This
allows you to keep your environment setting in one place, so you don't
have
to keep track of what to set before you ran and outside of METplus.
3) Inside the [user_env_vars] section, you can use filename templates
that
are used in the *_TEMPLATE variables. This is new functionality that
will
be in the 3.0 release, but it is not currently available in the latest
METplus release. You would do something like this:
In model.conf:
[user_env_vars]
VALID_DATE_YMD = {valid?fmt=%Y%m%d}
and in your GridStat config:
output_prefix = "${VALID_DATE_YMD}_ctc_sl2l2_${MODEL}_${OBTYPE}";
Please let me know if any of that is not clear or if you have any
other
questions!
Thanks,
George
On Thu, Sep 5, 2019 at 6:28 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> Thu Sep 05 12:27:49 2019: Request 91919 was acted upon.
> Transaction: Ticket created by ying.lin at noaa.gov
> Queue: met_help
> Subject: METplus: two levels of config files (model.conf and
> GRID_STAT_CONFIG_FILE)
> Owner: Nobody
> Requestors: ying.lin at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
>
>
> Hello. I have a question about the two levels of config files used
in
> METplus (let's say configs for GridStat), for a run like this:
>
> master_metplus.py \
> -c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
> -c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
>
> The first config file in question is fv3sar_24h.conf, and the second
> config is the GRID_STAT_CONFIG_FILE specified in (when(model=fv3sar)
> fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see
attached).
> I'd like to run the above for a number of models, all with the same
> thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like to
have
> the set up in common among all the models (for the 24h CTC and SL1L2
> verif) in the GRID_STAT_CONFIG_FILE, and to have ${mode}l_24h.conf
> containing just the model-specific info, like
FCST_PCP_COMBINE_METHOD,
> FCST_VAR1_NAME (in case there's an int'l model that uses an odd,
> non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably run a
> separate job to do PcpCombine and RegridDataPlane for the analysis,
> before running master_metplus.py for model verif (initially I
thought
> I'd run the PcpCombine/RegridDataPlane for the analysis with
> verification on the first model being verified, but it seems cleaner
to
> separate out the PcpCombine/RegridDataPlane for the analysis, in
case we
> need to turn verif for any specific model on/off temporarily).
Questions
> (I mean in below whether things can be done under the current
METplus,
> not whether it can be made possible in a future METplus):
>
> 1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If so,
> where/how to do that?
> 2. I tried listing all the poly files for the verifying regions in
> "poly" under "mask = { }" and it does work (see attached
> GridStatConfig_ctc_sl1l2). I specified the fulll path to each
poly
> .nc file because I couldn't figure out how to pass the mask
> directory to this config file. I tried "export
>
>
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
> in the calling script and "polydir = "${CONUS14}";" in the
> GRID_STAT_CONFIG_FILE (see attached
> GridStatConfig_ctc_sl1l2.poly.notwork), also added "CONUS14 =
> {ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export" to
> GRID_STAT_CONFIG_FILE is somehow done through the
fv3sar_24h.conf.
> It didn't work. How to export such a path name to
> GRID_STAT_CONFIG_FILE from the run script?
> 3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
> GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf to the
> GRID_STAT_CONFIG_FILE, that way if something needs to be changed
for
> all models it can be done just once in GRID_STAT_CONFIG_FILE?
>
> Thanks!
>
> Ying
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #91919] METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
From: Ying Lin
Time: Fri Sep 06 10:58:56 2019
Hi George,
Thank you for your reply. Follow up on the issues below:
1) Actually what I'd like is to specify FCST_VAR1_THRESH in the
GRID_STAT_CONFIG_FILE, since it's something that would be the same for
all the models being verified, and if it needs to be changed, it would
be handy to be able to change it in GRID_STAT_CONFIG_FILE rather than
each individual ${model}.conf. Is that possible in METplusv2.1?
2) Simple export of "polydir" works great, thanks! I was a bit
confused
about that since "exporting" to ${model}.conf was different.
Thanks again -
Ying
On 9/5/19 2:53 PM, George McCabe via RT wrote:
> Hi Ying,
>
> 1) Yes. When you set FCST_VAR1_THRESH, it will automatically be
added to
> the file specified by GRID_STAT_CONFIG_FILE. Look at the logs when
you run
> METplus, and you will see that the environment variable FCST_FIELD
contains
> the correct notation to specify the threshold values that you
specified in
> FCST_VAR1_THRESH. Here is an example:
>
> In parm/use_cases/qpf/examples/ruc-vs-s2grib.conf, we have:
>
> FCST_VAR1_NAME = APCP
> FCST_VAR1_LEVELS = A03
> FCST_VAR1_THRESH = gt12.7, gt25.4, gt50.8, gt76.2
>
> And in the log file from METplus:
>
> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135) DEBUG:
> FCST_FIELD={ name="APCP"; level="A03"; cat_thresh=[
> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135) DEBUG:
> OBS_FIELD={ name="APCP_03"; level="(*,*)"; cat_thresh=[
> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
>
> Generally the OBS_FIELD will be populated with the same values as
FCST_* if
> you don't specify OBS_*, but in this case, PcpCombine is run on the
> observation data prior to GridStat, so METplus formats this field
> information with that in mind.
>
> 2) To accomplish what you are trying to do, you don't need to create
a
> variable called polydir inside the GridStat config file. Instead,
you
> should name the environment variable polydir. Then you can reference
that
> environment variable directly.
> In your environment:
>
> export
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
>
> and in GridStat config:
>
> mask = {
> grid = ["FULL"];
> poly = [ "${polydir}/CONUS.nc", "${polydir}/APL.nc",
> "${polydir}/GMC.nc", "${polydir}/GRB.nc", "${polydir}/LMV.nc",
> "${polydir}/MDW.nc", "${polydir}/NEC.nc", "${polydir}/NMT.nc",
> "${polydir}/NPL.nc", "${polydir}/NWC.nc", "${polydir}/SEC.nc",
> "${polydir}/SMT.nc", "${polydir}/SPL.nc", "${polydir}/SWC.nc",
> "${polydir}/SWD.nc"];
> }
>
> This should work just fine. I am not sure how to reference other
variables
> with a MET (GridStat) config file, but there may be a way to do it,
but it
> is not necessary for this example.
>
> Another way to set the environment variable polydir is to add an
item to
> your model.conf file like this:
>
> [user_env_vars]
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
>
> This will create an environment variable called polydir and set it
only for
> your METplus runs, so it can be accessed by the GridStat config
file. This
> allows you to keep your environment setting in one place, so you
don't have
> to keep track of what to set before you ran and outside of METplus.
>
> 3) Inside the [user_env_vars] section, you can use filename
templates that
> are used in the *_TEMPLATE variables. This is new functionality that
will
> be in the 3.0 release, but it is not currently available in the
latest
> METplus release. You would do something like this:
>
> In model.conf:
>
> [user_env_vars]
> VALID_DATE_YMD = {valid?fmt=%Y%m%d}
>
> and in your GridStat config:
>
> output_prefix = "${VALID_DATE_YMD}_ctc_sl2l2_${MODEL}_${OBTYPE}";
>
>
>
> Please let me know if any of that is not clear or if you have any
other
> questions!
>
> Thanks,
> George
>
> On Thu, Sep 5, 2019 at 6:28 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> Thu Sep 05 12:27:49 2019: Request 91919 was acted upon.
>> Transaction: Ticket created by ying.lin at noaa.gov
>> Queue: met_help
>> Subject: METplus: two levels of config files (model.conf and
>> GRID_STAT_CONFIG_FILE)
>> Owner: Nobody
>> Requestors: ying.lin at noaa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
>>
>>
>> Hello. I have a question about the two levels of config files used
in
>> METplus (let's say configs for GridStat), for a run like this:
>>
>> master_metplus.py \
>> -c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
>> -c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
>>
>> The first config file in question is fv3sar_24h.conf, and the
second
>> config is the GRID_STAT_CONFIG_FILE specified in
(when(model=fv3sar)
>> fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see
attached).
>> I'd like to run the above for a number of models, all with the same
>> thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like to
have
>> the set up in common among all the models (for the 24h CTC and
SL1L2
>> verif) in the GRID_STAT_CONFIG_FILE, and to have ${mode}l_24h.conf
>> containing just the model-specific info, like
FCST_PCP_COMBINE_METHOD,
>> FCST_VAR1_NAME (in case there's an int'l model that uses an odd,
>> non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably run
a
>> separate job to do PcpCombine and RegridDataPlane for the analysis,
>> before running master_metplus.py for model verif (initially I
thought
>> I'd run the PcpCombine/RegridDataPlane for the analysis with
>> verification on the first model being verified, but it seems
cleaner to
>> separate out the PcpCombine/RegridDataPlane for the analysis, in
case we
>> need to turn verif for any specific model on/off temporarily).
Questions
>> (I mean in below whether things can be done under the current
METplus,
>> not whether it can be made possible in a future METplus):
>>
>> 1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If so,
>> where/how to do that?
>> 2. I tried listing all the poly files for the verifying regions
in
>> "poly" under "mask = { }" and it does work (see attached
>> GridStatConfig_ctc_sl1l2). I specified the fulll path to each
poly
>> .nc file because I couldn't figure out how to pass the mask
>> directory to this config file. I tried "export
>>
>>
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
>> in the calling script and "polydir = "${CONUS14}";" in the
>> GRID_STAT_CONFIG_FILE (see attached
>> GridStatConfig_ctc_sl1l2.poly.notwork), also added "CONUS14 =
>> {ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export" to
>> GRID_STAT_CONFIG_FILE is somehow done through the
fv3sar_24h.conf.
>> It didn't work. How to export such a path name to
>> GRID_STAT_CONFIG_FILE from the run script?
>> 3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
>> GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf to
the
>> GRID_STAT_CONFIG_FILE, that way if something needs to be
changed for
>> all models it can be done just once in GRID_STAT_CONFIG_FILE?
>>
>> Thanks!
>>
>> Ying
>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
Subject: METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
From: George McCabe
Time: Fri Sep 06 11:12:57 2019
Hi Ying,
There are a couple ways you could handle this. John may be able to
provide
more insight for the 2nd approach.
1) Create another METplus config file that just has something like:
[config]
FCST_VAR<n>_THRESH = gt2, ...
Then source that conf file in your call to master metplus. If this new
file
was called thresholds.conf, you would call:
master_metplus.py -c model.conf -c thresholds.conf -c system.conf
This would override the thresholds regardless of model. The downside
of
this is you would have to create one for each VAR<n> that you have,
and
that may vary across models/runs.
2) You can set cat_thresh outside of the fcst and obs dictionaries and
it
will apply to all of the fields. If you don't set FCST_VAR*_THRESH in
METplus, the value in the GridStat config will be used for all.
cat_thresh = [ ... ]
fcst = { ...
If you need to only set the fcst thresholds and not the obs, I believe
you
could put the following after the fcst and obs dictionary definitions:
fcst = {
field = [ ${FCST_FIELD} ];
}
obs = {
field = [ ${OBS_FIELD} ];
}
*fcst.cat_thresh = [ ... ]*
I am not 100% positive that you can do that, but if you can, then that
would apply the threshold to all fcst fields in your list.
On Fri, Sep 6, 2019 at 10:59 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
>
> Hi George,
>
> Thank you for your reply. Follow up on the issues below:
>
> 1) Actually what I'd like is to specify FCST_VAR1_THRESH in the
> GRID_STAT_CONFIG_FILE, since it's something that would be the same
for
> all the models being verified, and if it needs to be changed, it
would
> be handy to be able to change it in GRID_STAT_CONFIG_FILE rather
than
> each individual ${model}.conf. Is that possible in METplusv2.1?
>
> 2) Simple export of "polydir" works great, thanks! I was a bit
confused
> about that since "exporting" to ${model}.conf was different.
>
> Thanks again -
>
> Ying
>
>
> On 9/5/19 2:53 PM, George McCabe via RT wrote:
> > Hi Ying,
> >
> > 1) Yes. When you set FCST_VAR1_THRESH, it will automatically be
added to
> > the file specified by GRID_STAT_CONFIG_FILE. Look at the logs when
you
> run
> > METplus, and you will see that the environment variable FCST_FIELD
> contains
> > the correct notation to specify the threshold values that you
specified
> in
> > FCST_VAR1_THRESH. Here is an example:
> >
> > In parm/use_cases/qpf/examples/ruc-vs-s2grib.conf, we have:
> >
> > FCST_VAR1_NAME = APCP
> > FCST_VAR1_LEVELS = A03
> > FCST_VAR1_THRESH = gt12.7, gt25.4, gt50.8, gt76.2
> >
> > And in the log file from METplus:
> >
> > 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
> > FCST_FIELD={ name="APCP"; level="A03"; cat_thresh=[
> > gt12.7,gt25.4,gt50.8,gt76.2 ]; }
> > 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
> > OBS_FIELD={ name="APCP_03"; level="(*,*)"; cat_thresh=[
> > gt12.7,gt25.4,gt50.8,gt76.2 ]; }
> >
> > Generally the OBS_FIELD will be populated with the same values as
FCST_*
> if
> > you don't specify OBS_*, but in this case, PcpCombine is run on
the
> > observation data prior to GridStat, so METplus formats this field
> > information with that in mind.
> >
> > 2) To accomplish what you are trying to do, you don't need to
create a
> > variable called polydir inside the GridStat config file. Instead,
you
> > should name the environment variable polydir. Then you can
reference that
> > environment variable directly.
> > In your environment:
> >
> > export
> >
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
> >
> > and in GridStat config:
> >
> > mask = {
> > grid = ["FULL"];
> > poly = [ "${polydir}/CONUS.nc", "${polydir}/APL.nc",
> > "${polydir}/GMC.nc", "${polydir}/GRB.nc", "${polydir}/LMV.nc",
> > "${polydir}/MDW.nc", "${polydir}/NEC.nc", "${polydir}/NMT.nc",
> > "${polydir}/NPL.nc", "${polydir}/NWC.nc", "${polydir}/SEC.nc",
> > "${polydir}/SMT.nc", "${polydir}/SPL.nc", "${polydir}/SWC.nc",
> > "${polydir}/SWD.nc"];
> > }
> >
> > This should work just fine. I am not sure how to reference other
> variables
> > with a MET (GridStat) config file, but there may be a way to do
it, but
> it
> > is not necessary for this example.
> >
> > Another way to set the environment variable polydir is to add an
item to
> > your model.conf file like this:
> >
> > [user_env_vars]
> >
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
> >
> > This will create an environment variable called polydir and set it
only
> for
> > your METplus runs, so it can be accessed by the GridStat config
file.
> This
> > allows you to keep your environment setting in one place, so you
don't
> have
> > to keep track of what to set before you ran and outside of
METplus.
> >
> > 3) Inside the [user_env_vars] section, you can use filename
templates
> that
> > are used in the *_TEMPLATE variables. This is new functionality
that will
> > be in the 3.0 release, but it is not currently available in the
latest
> > METplus release. You would do something like this:
> >
> > In model.conf:
> >
> > [user_env_vars]
> > VALID_DATE_YMD = {valid?fmt=%Y%m%d}
> >
> > and in your GridStat config:
> >
> > output_prefix =
"${VALID_DATE_YMD}_ctc_sl2l2_${MODEL}_${OBTYPE}";
> >
> >
> >
> > Please let me know if any of that is not clear or if you have any
other
> > questions!
> >
> > Thanks,
> > George
> >
> > On Thu, Sep 5, 2019 at 6:28 PM Ying Lin via RT <met_help at ucar.edu>
> wrote:
> >
> >> Thu Sep 05 12:27:49 2019: Request 91919 was acted upon.
> >> Transaction: Ticket created by ying.lin at noaa.gov
> >> Queue: met_help
> >> Subject: METplus: two levels of config files (model.conf
and
> >> GRID_STAT_CONFIG_FILE)
> >> Owner: Nobody
> >> Requestors: ying.lin at noaa.gov
> >> Status: new
> >> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919
> >
> >>
> >>
> >> Hello. I have a question about the two levels of config files
used in
> >> METplus (let's say configs for GridStat), for a run like this:
> >>
> >> master_metplus.py \
> >> -c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
> >> -c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
> >>
> >> The first config file in question is fv3sar_24h.conf, and the
second
> >> config is the GRID_STAT_CONFIG_FILE specified in
(when(model=fv3sar)
> >> fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see
attached).
> >> I'd like to run the above for a number of models, all with the
same
> >> thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like to
have
> >> the set up in common among all the models (for the 24h CTC and
SL1L2
> >> verif) in the GRID_STAT_CONFIG_FILE, and to have
${mode}l_24h.conf
> >> containing just the model-specific info, like
FCST_PCP_COMBINE_METHOD,
> >> FCST_VAR1_NAME (in case there's an int'l model that uses an odd,
> >> non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably
run a
> >> separate job to do PcpCombine and RegridDataPlane for the
analysis,
> >> before running master_metplus.py for model verif (initially I
thought
> >> I'd run the PcpCombine/RegridDataPlane for the analysis with
> >> verification on the first model being verified, but it seems
cleaner to
> >> separate out the PcpCombine/RegridDataPlane for the analysis, in
case we
> >> need to turn verif for any specific model on/off temporarily).
Questions
> >> (I mean in below whether things can be done under the current
METplus,
> >> not whether it can be made possible in a future METplus):
> >>
> >> 1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If
so,
> >> where/how to do that?
> >> 2. I tried listing all the poly files for the verifying regions
in
> >> "poly" under "mask = { }" and it does work (see attached
> >> GridStatConfig_ctc_sl1l2). I specified the fulll path to
each poly
> >> .nc file because I couldn't figure out how to pass the mask
> >> directory to this config file. I tried "export
> >>
> >>
>
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
> >> in the calling script and "polydir = "${CONUS14}";" in the
> >> GRID_STAT_CONFIG_FILE (see attached
> >> GridStatConfig_ctc_sl1l2.poly.notwork), also added "CONUS14
=
> >> {ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export" to
> >> GRID_STAT_CONFIG_FILE is somehow done through the
fv3sar_24h.conf.
> >> It didn't work. How to export such a path name to
> >> GRID_STAT_CONFIG_FILE from the run script?
> >> 3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
> >> GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf to
the
> >> GRID_STAT_CONFIG_FILE, that way if something needs to be
changed
> for
> >> all models it can be done just once in
GRID_STAT_CONFIG_FILE?
> >>
> >> Thanks!
> >>
> >> Ying
> >>
> >> --
> >> Ying Lin
> >> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >> NCWCP Cubicle No. 2015
> >> Ying.Lin at noaa.gov
> >>
> >>
> >>
> >>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
Subject: METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
From: Ying Lin
Time: Fri Sep 06 13:44:25 2019
Hi George,
Hmm, come to think of it, maybe specifying the threshold in
${model}_conf isn't so bad after all ...
I'm stumped on another issue - have been setting up the
PcpCombine
and RegridDataPlane for the analysis ahead of running
PcpCombine/GridStat for individual models
(ftp://ftp.emc.ncep.noaa.gov/mmb/precip/METplus.question/prep_ccpa24h.conf),
so the analysis processing is done only once. The analysis
processing
itself seems to be OK, but when I verif for a model (fv3sar) after the
analysis processing (run_all.sh in the above ftp directory), I get (in
master_metplus.log.20190906).
------------------------------------------------------------------
DEBUG 1: Forecast File:
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/fv3sar/bucket/fv3sar.2019090400_f036_a24h
DEBUG 1: Observation File:
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/ccpa/regrid/20190905/ccpa.2019090512_a24h.g212
DEBUG 1: Regridding field APCP_24(*,*) to the verification grid.
WARNING:
WARNING: read_data_plane() -> APCPA24 not found in file:
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/ccpa/regrid/20190905/ccpa.2019090512_a24h.g212
WARNING:
ERROR :
ERROR : process_scores() -> no requested data found! Exiting...
----------------------------------------------------------
If I process the analysis along with the forecast and do the GridStat
in
a single metplus.py run (run_all_works.sh, fv3sar_24h.conf.works),
then
it works fine. I compared the regridded ccpa.2019090512_a24h.g212
from
the two different runs (ccpa.2019090512_a24h.g212.pre-made and
ccpa.2019090512_a24h.g212, they seem to be identical according to
'ncdump -h'. There isn't a difference in the analysis field name, so
the difference is probably from some variable in fv3sar_24h.conf vs.
fv3sar_24h.conf.works. I can't figure out what it is though. Would
you
mind taking a look?
My original fv3sar_24h.conf didn't have
OBS_VAR1_NAME = APCP
OBS_VAR1_LEVELS = A24
I thought maybe adding the above two lines would make a difference.
It
didn't.
Also, is the "Regridding field APCP_24(*,*) to the verification grid"
in
the quoted err msg above separate from the "RegridDataPlane" and
"OBS_REGRID_DATA_PLANE_RUN" in the fv3sar_24h.conf? I thought the OBS
(analysis) has already been "Regridded" to g212, and the regridding
during GridStat is just done to the forecast grid.
Thank you again -
Ying
On 9/6/19 1:12 PM, George McCabe via RT wrote:
> Hi Ying,
>
> There are a couple ways you could handle this. John may be able to
provide
> more insight for the 2nd approach.
>
> 1) Create another METplus config file that just has something like:
>
> [config]
> FCST_VAR<n>_THRESH = gt2, ...
>
> Then source that conf file in your call to master metplus. If this
new file
> was called thresholds.conf, you would call:
>
> master_metplus.py -c model.conf -c thresholds.conf -c system.conf
>
> This would override the thresholds regardless of model. The downside
of
> this is you would have to create one for each VAR<n> that you have,
and
> that may vary across models/runs.
>
> 2) You can set cat_thresh outside of the fcst and obs dictionaries
and it
> will apply to all of the fields. If you don't set FCST_VAR*_THRESH
in
> METplus, the value in the GridStat config will be used for all.
>
> cat_thresh = [ ... ]
> fcst = { ...
>
> If you need to only set the fcst thresholds and not the obs, I
believe you
> could put the following after the fcst and obs dictionary
definitions:
>
> fcst = {
> field = [ ${FCST_FIELD} ];
> }
> obs = {
> field = [ ${OBS_FIELD} ];
> }
>
> *fcst.cat_thresh = [ ... ]*
>
> I am not 100% positive that you can do that, but if you can, then
that
> would apply the threshold to all fcst fields in your list.
>
>
>
> On Fri, Sep 6, 2019 at 10:59 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
>>
>> Hi George,
>>
>> Thank you for your reply. Follow up on the issues below:
>>
>> 1) Actually what I'd like is to specify FCST_VAR1_THRESH in the
>> GRID_STAT_CONFIG_FILE, since it's something that would be the same
for
>> all the models being verified, and if it needs to be changed, it
would
>> be handy to be able to change it in GRID_STAT_CONFIG_FILE rather
than
>> each individual ${model}.conf. Is that possible in METplusv2.1?
>>
>> 2) Simple export of "polydir" works great, thanks! I was a bit
confused
>> about that since "exporting" to ${model}.conf was different.
>>
>> Thanks again -
>>
>> Ying
>>
>>
>> On 9/5/19 2:53 PM, George McCabe via RT wrote:
>>> Hi Ying,
>>>
>>> 1) Yes. When you set FCST_VAR1_THRESH, it will automatically be
added to
>>> the file specified by GRID_STAT_CONFIG_FILE. Look at the logs when
you
>> run
>>> METplus, and you will see that the environment variable FCST_FIELD
>> contains
>>> the correct notation to specify the threshold values that you
specified
>> in
>>> FCST_VAR1_THRESH. Here is an example:
>>>
>>> In parm/use_cases/qpf/examples/ruc-vs-s2grib.conf, we have:
>>>
>>> FCST_VAR1_NAME = APCP
>>> FCST_VAR1_LEVELS = A03
>>> FCST_VAR1_THRESH = gt12.7, gt25.4, gt50.8, gt76.2
>>>
>>> And in the log file from METplus:
>>>
>>> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
>>> FCST_FIELD={ name="APCP"; level="A03"; cat_thresh=[
>>> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
>>> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
>>> OBS_FIELD={ name="APCP_03"; level="(*,*)"; cat_thresh=[
>>> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
>>>
>>> Generally the OBS_FIELD will be populated with the same values as
FCST_*
>> if
>>> you don't specify OBS_*, but in this case, PcpCombine is run on
the
>>> observation data prior to GridStat, so METplus formats this field
>>> information with that in mind.
>>>
>>> 2) To accomplish what you are trying to do, you don't need to
create a
>>> variable called polydir inside the GridStat config file. Instead,
you
>>> should name the environment variable polydir. Then you can
reference that
>>> environment variable directly.
>>> In your environment:
>>>
>>> export
>>>
>>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
>>> and in GridStat config:
>>>
>>> mask = {
>>> grid = ["FULL"];
>>> poly = [ "${polydir}/CONUS.nc", "${polydir}/APL.nc",
>>> "${polydir}/GMC.nc", "${polydir}/GRB.nc", "${polydir}/LMV.nc",
>>> "${polydir}/MDW.nc", "${polydir}/NEC.nc", "${polydir}/NMT.nc",
>>> "${polydir}/NPL.nc", "${polydir}/NWC.nc", "${polydir}/SEC.nc",
>>> "${polydir}/SMT.nc", "${polydir}/SPL.nc", "${polydir}/SWC.nc",
>>> "${polydir}/SWD.nc"];
>>> }
>>>
>>> This should work just fine. I am not sure how to reference other
>> variables
>>> with a MET (GridStat) config file, but there may be a way to do
it, but
>> it
>>> is not necessary for this example.
>>>
>>> Another way to set the environment variable polydir is to add an
item to
>>> your model.conf file like this:
>>>
>>> [user_env_vars]
>>>
>>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
>>> This will create an environment variable called polydir and set it
only
>> for
>>> your METplus runs, so it can be accessed by the GridStat config
file.
>> This
>>> allows you to keep your environment setting in one place, so you
don't
>> have
>>> to keep track of what to set before you ran and outside of
METplus.
>>>
>>> 3) Inside the [user_env_vars] section, you can use filename
templates
>> that
>>> are used in the *_TEMPLATE variables. This is new functionality
that will
>>> be in the 3.0 release, but it is not currently available in the
latest
>>> METplus release. You would do something like this:
>>>
>>> In model.conf:
>>>
>>> [user_env_vars]
>>> VALID_DATE_YMD = {valid?fmt=%Y%m%d}
>>>
>>> and in your GridStat config:
>>>
>>> output_prefix =
"${VALID_DATE_YMD}_ctc_sl2l2_${MODEL}_${OBTYPE}";
>>>
>>>
>>>
>>> Please let me know if any of that is not clear or if you have any
other
>>> questions!
>>>
>>> Thanks,
>>> George
>>>
>>> On Thu, Sep 5, 2019 at 6:28 PM Ying Lin via RT <met_help at ucar.edu>
>> wrote:
>>>> Thu Sep 05 12:27:49 2019: Request 91919 was acted upon.
>>>> Transaction: Ticket created by ying.lin at noaa.gov
>>>> Queue: met_help
>>>> Subject: METplus: two levels of config files (model.conf
and
>>>> GRID_STAT_CONFIG_FILE)
>>>> Owner: Nobody
>>>> Requestors: ying.lin at noaa.gov
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919
>>>>
>>>> Hello. I have a question about the two levels of config files
used in
>>>> METplus (let's say configs for GridStat), for a run like this:
>>>>
>>>> master_metplus.py \
>>>> -c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
>>>> -c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
>>>>
>>>> The first config file in question is fv3sar_24h.conf, and the
second
>>>> config is the GRID_STAT_CONFIG_FILE specified in
(when(model=fv3sar)
>>>> fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see
attached).
>>>> I'd like to run the above for a number of models, all with the
same
>>>> thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like to
have
>>>> the set up in common among all the models (for the 24h CTC and
SL1L2
>>>> verif) in the GRID_STAT_CONFIG_FILE, and to have
${mode}l_24h.conf
>>>> containing just the model-specific info, like
FCST_PCP_COMBINE_METHOD,
>>>> FCST_VAR1_NAME (in case there's an int'l model that uses an odd,
>>>> non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably
run a
>>>> separate job to do PcpCombine and RegridDataPlane for the
analysis,
>>>> before running master_metplus.py for model verif (initially I
thought
>>>> I'd run the PcpCombine/RegridDataPlane for the analysis with
>>>> verification on the first model being verified, but it seems
cleaner to
>>>> separate out the PcpCombine/RegridDataPlane for the analysis, in
case we
>>>> need to turn verif for any specific model on/off temporarily).
Questions
>>>> (I mean in below whether things can be done under the current
METplus,
>>>> not whether it can be made possible in a future METplus):
>>>>
>>>> 1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If
so,
>>>> where/how to do that?
>>>> 2. I tried listing all the poly files for the verifying
regions in
>>>> "poly" under "mask = { }" and it does work (see attached
>>>> GridStatConfig_ctc_sl1l2). I specified the fulll path to
each poly
>>>> .nc file because I couldn't figure out how to pass the mask
>>>> directory to this config file. I tried "export
>>>>
>>>>
>>
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
>>>> in the calling script and "polydir = "${CONUS14}";" in the
>>>> GRID_STAT_CONFIG_FILE (see attached
>>>> GridStatConfig_ctc_sl1l2.poly.notwork), also added "CONUS14
=
>>>> {ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export" to
>>>> GRID_STAT_CONFIG_FILE is somehow done through the
fv3sar_24h.conf.
>>>> It didn't work. How to export such a path name to
>>>> GRID_STAT_CONFIG_FILE from the run script?
>>>> 3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
>>>> GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf
to the
>>>> GRID_STAT_CONFIG_FILE, that way if something needs to be
changed
>> for
>>>> all models it can be done just once in
GRID_STAT_CONFIG_FILE?
>>>>
>>>> Thanks!
>>>>
>>>> Ying
>>>>
>>>> --
>>>> Ying Lin
>>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>>>> NCWCP Cubicle No. 2015
>>>> Ying.Lin at noaa.gov
>>>>
>>>>
>>>>
>>>>
>> --
>> Ying Lin
>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
>> NCWCP Cubicle No. 2015
>> Ying.Lin at noaa.gov
>>
>>
>>
>>
--
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
------------------------------------------------
Subject: METplus: two levels of config files (model.conf and GRID_STAT_CONFIG_FILE)
From: George McCabe
Time: Wed Oct 02 08:29:25 2019
Hi Ying,
Did we resolve all of these issues in person? I am closing this
ticket, but
please reply to re-open it if you are still having these issues.
Thanks.
On Fri, Sep 6, 2019 at 3:08 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
>
> Hi George,
>
> Hmm, come to think of it, maybe specifying the threshold in
> ${model}_conf isn't so bad after all ...
>
> I'm stumped on another issue - have been setting up the
PcpCombine
> and RegridDataPlane for the analysis ahead of running
> PcpCombine/GridStat for individual models
>
(ftp://ftp.emc.ncep.noaa.gov/mmb/precip/METplus.question/prep_ccpa24h.conf),
>
> so the analysis processing is done only once. The analysis
processing
> itself seems to be OK, but when I verif for a model (fv3sar) after
the
> analysis processing (run_all.sh in the above ftp directory), I get
(in
> master_metplus.log.20190906).
> ------------------------------------------------------------------
>
> DEBUG 1: Forecast File:
>
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/fv3sar/bucket/fv3sar.2019090400_f036_a24h
> DEBUG 1: Observation File:
>
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/ccpa/regrid/20190905/ccpa.2019090512_a24h.g212
> DEBUG 1: Regridding field APCP_24(*,*) to the verification grid.
> WARNING:
> WARNING: read_data_plane() -> APCPA24 not found in file:
>
/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus.out/ccpa/regrid/20190905/ccpa.2019090512_a24h.g212
> WARNING:
> ERROR :
> ERROR : process_scores() -> no requested data found! Exiting...
> ----------------------------------------------------------
>
> If I process the analysis along with the forecast and do the
GridStat in
> a single metplus.py run (run_all_works.sh, fv3sar_24h.conf.works),
then
> it works fine. I compared the regridded ccpa.2019090512_a24h.g212
from
> the two different runs (ccpa.2019090512_a24h.g212.pre-made and
> ccpa.2019090512_a24h.g212, they seem to be identical according to
> 'ncdump -h'. There isn't a difference in the analysis field name,
so
> the difference is probably from some variable in fv3sar_24h.conf vs.
> fv3sar_24h.conf.works. I can't figure out what it is though. Would
you
> mind taking a look?
>
> My original fv3sar_24h.conf didn't have
> OBS_VAR1_NAME = APCP
> OBS_VAR1_LEVELS = A24
>
> I thought maybe adding the above two lines would make a difference.
It
> didn't.
>
> Also, is the "Regridding field APCP_24(*,*) to the verification
grid" in
> the quoted err msg above separate from the "RegridDataPlane" and
> "OBS_REGRID_DATA_PLANE_RUN" in the fv3sar_24h.conf? I thought the
OBS
> (analysis) has already been "Regridded" to g212, and the regridding
> during GridStat is just done to the forecast grid.
>
> Thank you again -
>
> Ying
>
> On 9/6/19 1:12 PM, George McCabe via RT wrote:
> > Hi Ying,
> >
> > There are a couple ways you could handle this. John may be able to
> provide
> > more insight for the 2nd approach.
> >
> > 1) Create another METplus config file that just has something
like:
> >
> > [config]
> > FCST_VAR<n>_THRESH = gt2, ...
> >
> > Then source that conf file in your call to master metplus. If this
new
> file
> > was called thresholds.conf, you would call:
> >
> > master_metplus.py -c model.conf -c thresholds.conf -c system.conf
> >
> > This would override the thresholds regardless of model. The
downside of
> > this is you would have to create one for each VAR<n> that you
have, and
> > that may vary across models/runs.
> >
> > 2) You can set cat_thresh outside of the fcst and obs dictionaries
and it
> > will apply to all of the fields. If you don't set FCST_VAR*_THRESH
in
> > METplus, the value in the GridStat config will be used for all.
> >
> > cat_thresh = [ ... ]
> > fcst = { ...
> >
> > If you need to only set the fcst thresholds and not the obs, I
believe
> you
> > could put the following after the fcst and obs dictionary
definitions:
> >
> > fcst = {
> > field = [ ${FCST_FIELD} ];
> > }
> > obs = {
> > field = [ ${OBS_FIELD} ];
> > }
> >
> > *fcst.cat_thresh = [ ... ]*
> >
> > I am not 100% positive that you can do that, but if you can, then
that
> > would apply the threshold to all fcst fields in your list.
> >
> >
> >
> > On Fri, Sep 6, 2019 at 10:59 AM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919 >
> >>
> >> Hi George,
> >>
> >> Thank you for your reply. Follow up on the issues below:
> >>
> >> 1) Actually what I'd like is to specify FCST_VAR1_THRESH in the
> >> GRID_STAT_CONFIG_FILE, since it's something that would be the
same for
> >> all the models being verified, and if it needs to be changed, it
would
> >> be handy to be able to change it in GRID_STAT_CONFIG_FILE rather
than
> >> each individual ${model}.conf. Is that possible in METplusv2.1?
> >>
> >> 2) Simple export of "polydir" works great, thanks! I was a bit
confused
> >> about that since "exporting" to ${model}.conf was different.
> >>
> >> Thanks again -
> >>
> >> Ying
> >>
> >>
> >> On 9/5/19 2:53 PM, George McCabe via RT wrote:
> >>> Hi Ying,
> >>>
> >>> 1) Yes. When you set FCST_VAR1_THRESH, it will automatically be
added
> to
> >>> the file specified by GRID_STAT_CONFIG_FILE. Look at the logs
when you
> >> run
> >>> METplus, and you will see that the environment variable
FCST_FIELD
> >> contains
> >>> the correct notation to specify the threshold values that you
specified
> >> in
> >>> FCST_VAR1_THRESH. Here is an example:
> >>>
> >>> In parm/use_cases/qpf/examples/ruc-vs-s2grib.conf, we have:
> >>>
> >>> FCST_VAR1_NAME = APCP
> >>> FCST_VAR1_LEVELS = A03
> >>> FCST_VAR1_THRESH = gt12.7, gt25.4, gt50.8, gt76.2
> >>>
> >>> And in the log file from METplus:
> >>>
> >>> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
> >>> FCST_FIELD={ name="APCP"; level="A03"; cat_thresh=[
> >>> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
> >>> 08/30 17:05:24.930 metplus.GridStat (command_builder.py:135)
DEBUG:
> >>> OBS_FIELD={ name="APCP_03"; level="(*,*)"; cat_thresh=[
> >>> gt12.7,gt25.4,gt50.8,gt76.2 ]; }
> >>>
> >>> Generally the OBS_FIELD will be populated with the same values
as
> FCST_*
> >> if
> >>> you don't specify OBS_*, but in this case, PcpCombine is run on
the
> >>> observation data prior to GridStat, so METplus formats this
field
> >>> information with that in mind.
> >>>
> >>> 2) To accomplish what you are trying to do, you don't need to
create a
> >>> variable called polydir inside the GridStat config file.
Instead, you
> >>> should name the environment variable polydir. Then you can
reference
> that
> >>> environment variable directly.
> >>> In your environment:
> >>>
> >>> export
> >>>
> >>
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
> >>> and in GridStat config:
> >>>
> >>> mask = {
> >>> grid = ["FULL"];
> >>> poly = [ "${polydir}/CONUS.nc", "${polydir}/APL.nc",
> >>> "${polydir}/GMC.nc", "${polydir}/GRB.nc", "${polydir}/LMV.nc",
> >>> "${polydir}/MDW.nc", "${polydir}/NEC.nc", "${polydir}/NMT.nc",
> >>> "${polydir}/NPL.nc", "${polydir}/NWC.nc", "${polydir}/SEC.nc",
> >>> "${polydir}/SMT.nc", "${polydir}/SPL.nc", "${polydir}/SWC.nc",
> >>> "${polydir}/SWD.nc"];
> >>> }
> >>>
> >>> This should work just fine. I am not sure how to reference other
> >> variables
> >>> with a MET (GridStat) config file, but there may be a way to do
it, but
> >> it
> >>> is not necessary for this example.
> >>>
> >>> Another way to set the environment variable polydir is to add an
item
> to
> >>> your model.conf file like this:
> >>>
> >>> [user_env_vars]
> >>>
> >>
>
polydir=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14
> >>> This will create an environment variable called polydir and set
it only
> >> for
> >>> your METplus runs, so it can be accessed by the GridStat config
file.
> >> This
> >>> allows you to keep your environment setting in one place, so you
don't
> >> have
> >>> to keep track of what to set before you ran and outside of
METplus.
> >>>
> >>> 3) Inside the [user_env_vars] section, you can use filename
templates
> >> that
> >>> are used in the *_TEMPLATE variables. This is new functionality
that
> will
> >>> be in the 3.0 release, but it is not currently available in the
latest
> >>> METplus release. You would do something like this:
> >>>
> >>> In model.conf:
> >>>
> >>> [user_env_vars]
> >>> VALID_DATE_YMD = {valid?fmt=%Y%m%d}
> >>>
> >>> and in your GridStat config:
> >>>
> >>> output_prefix =
"${VALID_DATE_YMD}_ctc_sl2l2_${MODEL}_${OBTYPE}";
> >>>
> >>>
> >>>
> >>> Please let me know if any of that is not clear or if you have
any other
> >>> questions!
> >>>
> >>> Thanks,
> >>> George
> >>>
> >>> On Thu, Sep 5, 2019 at 6:28 PM Ying Lin via RT
<met_help at ucar.edu>
> >> wrote:
> >>>> Thu Sep 05 12:27:49 2019: Request 91919 was acted upon.
> >>>> Transaction: Ticket created by ying.lin at noaa.gov
> >>>> Queue: met_help
> >>>> Subject: METplus: two levels of config files (model.conf
and
> >>>> GRID_STAT_CONFIG_FILE)
> >>>> Owner: Nobody
> >>>> Requestors: ying.lin at noaa.gov
> >>>> Status: new
> >>>> Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=91919
> >>>>
> >>>> Hello. I have a question about the two levels of config files
used in
> >>>> METplus (let's say configs for GridStat), for a run like this:
> >>>>
> >>>> master_metplus.py \
> >>>> -c ${YLMETPLUS_PATH}/yl/parm/models/${mode}l_24h.conf \
> >>>> -c ${YLMETPLUS_PATH}/yl/parm/system.conf.dell
> >>>>
> >>>> The first config file in question is fv3sar_24h.conf, and the
second
> >>>> config is the GRID_STAT_CONFIG_FILE specified in
(when(model=fv3sar)
> >>>> fv3sar_24h.conf (in my case, GridStatConfig_ctc_sl1l2 - see
> attached).
> >>>> I'd like to run the above for a number of models, all with the
same
> >>>> thresholds (FCST_VAR1_THRESH), sub-region masks. So I'd like
to have
> >>>> the set up in common among all the models (for the 24h CTC and
SL1L2
> >>>> verif) in the GRID_STAT_CONFIG_FILE, and to have
${mode}l_24h.conf
> >>>> containing just the model-specific info, like
FCST_PCP_COMBINE_METHOD,
> >>>> FCST_VAR1_NAME (in case there's an int'l model that uses an
odd,
> >>>> non-APCP parm for precip). FCST_*_TEMPLATE, etc. I'd probably
run a
> >>>> separate job to do PcpCombine and RegridDataPlane for the
analysis,
> >>>> before running master_metplus.py for model verif (initially I
thought
> >>>> I'd run the PcpCombine/RegridDataPlane for the analysis with
> >>>> verification on the first model being verified, but it seems
cleaner
> to
> >>>> separate out the PcpCombine/RegridDataPlane for the analysis,
in case
> we
> >>>> need to turn verif for any specific model on/off temporarily).
> Questions
> >>>> (I mean in below whether things can be done under the current
METplus,
> >>>> not whether it can be made possible in a future METplus):
> >>>>
> >>>> 1. Can FCST_VAR1_THRESH be set in GRID_STAT_CONFIG_FILE? If
so,
> >>>> where/how to do that?
> >>>> 2. I tried listing all the poly files for the verifying
regions in
> >>>> "poly" under "mask = { }" and it does work (see
attached
> >>>> GridStatConfig_ctc_sl1l2). I specified the fulll path to
each
> poly
> >>>> .nc file because I couldn't figure out how to pass the
mask
> >>>> directory to this config file. I tried "export
> >>>>
> >>>>
> >>
>
CONUS14=/gpfs/dell2/emc/verification/noscrub/Ying.Lin/metplus/yl/masks/conus14"
> >>>> in the calling script and "polydir = "${CONUS14}";" in
the
> >>>> GRID_STAT_CONFIG_FILE (see attached
> >>>> GridStatConfig_ctc_sl1l2.poly.notwork), also added
"CONUS14 =
> >>>> {ENV[CONUS14]}" in fv3sar_24h.conf, in case the "export"
to
> >>>> GRID_STAT_CONFIG_FILE is somehow done through the
> fv3sar_24h.conf.
> >>>> It didn't work. How to export such a path name to
> >>>> GRID_STAT_CONFIG_FILE from the run script?
> >>>> 3. Can things such as OBS_GRID_STAT_INPUT_TEMPLATE and
> >>>> GRID_STAT_OUTPUT_TEMPLATE be moved from ${model}_24h.conf
to the
> >>>> GRID_STAT_CONFIG_FILE, that way if something needs to be
changed
> >> for
> >>>> all models it can be done just once in
GRID_STAT_CONFIG_FILE?
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Ying
> >>>>
> >>>> --
> >>>> Ying Lin
> >>>> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >>>> NCWCP Cubicle No. 2015
> >>>> Ying.Lin at noaa.gov
> >>>>
> >>>>
> >>>>
> >>>>
> >> --
> >> Ying Lin
> >> NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> >> NCWCP Cubicle No. 2015
> >> Ying.Lin at noaa.gov
> >>
> >>
> >>
> >>
>
> --
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list