Update develop-ref after MET#2975

.github/workflows/build_docker_and_trigger_metplus.yml

@@ -5,7 +5,7 @@ on:
     branches:
       - develop
     paths-ignore:
-      - 'met/docs/**'
+      - 'docs/**'
 
   workflow_dispatch:
 

data/config/GenEnsProdConfig_default

@@ -13,7 +13,6 @@ model = "FCST";
 
 //
 // Output description to be written
-// May be set separately in each "obs.field" entry
 //
 desc = "NA";
 

docs/Users_Guide/appendixA.rst

@@ -515,7 +515,7 @@ Q. What is an example of using Grid-Stat with regridding and masking turned on?
      This tells Grid-Stat to do verification on the "observation" grid.
      Grid-Stat reads the GFS and Stage4 data and then automatically regrids
      the GFS data to the Stage4 domain using budget interpolation.
-     Use "FCST" to verify the forecast domain. And use either a named
+     Use FCST to verify the forecast domain. And use either a named
      grid or a grid specification string to regrid both the forecast and
      observation to a common grid. For example, to_grid = "G212"; will
      regrid both to NCEP Grid 212 before comparing them.

docs/Users_Guide/appendixF.rst

@@ -368,7 +368,7 @@ The Ensemble-Stat, Series-Analysis, MTD and Gen-Ens-Prod tools all have the abil
 
    gen_ens_prod ens1.nc ens2.nc ens3.nc ens4.nc -out ens_prod.nc -config GenEnsProd_config
 
-In this case, a user is passing 4 ensemble members to Gen-Ens-Prod to be evaluated, and each member is in a separate file. If a user wishes to use Python embedding to process the ensemble input files, then the same exact command is used however special modifications inside the GenEnsProd_config file are needed. In the config file dictionary, the user must set the **file_type** entry to either **PYTHON_NUMPY** or **PYTHON_XARRAY** to activate the Python embedding for these tools. Then, in the **name** entry of the config file dictionaries for the forecast or observation data, the user must list the **full path** to the Python script to be run. However, in the Python command, replace the name of the input gridded data file to the Python script with the constant string **MET_PYTHON_INPUT_ARG**. When looping over all of the input files, the MET tools will replace that constant **MET_PYTHON_INPUT_ARG** with the path to the input file currently being processed and optionally, any command line arguments for the Python script. Here is what this looks like in the GenEnsProd_config file for the above example:
+In this case, a user is passing 4 ensemble members to Gen-Ens-Prod to be evaluated, and each member is in a separate file. If a user wishes to use Python embedding to process the ensemble input files, then the same exact command is used; however special modifications inside the GenEnsProd_config file are needed. In the config file dictionary, the user must set the **file_type** entry to either **PYTHON_NUMPY** or **PYTHON_XARRAY** to activate the Python embedding for these tools. Then, in the **name** entry of the config file dictionaries for the forecast or observation data, the user must list the **full path** to the Python script to be run. However, in the Python command, replace the name of the input gridded data file to the Python script with the constant string **MET_PYTHON_INPUT_ARG**. When looping over all of the input files, the MET tools will replace that constant **MET_PYTHON_INPUT_ARG** with the path to the input file currently being processed and optionally, any command line arguments for the Python script. Here is what this looks like in the GenEnsProd_config file for the above example:
 
 .. code-block::
    :caption: Gen-Ens-Prod MET_PYTHON_INPUT_ARG Config

docs/Users_Guide/config_options_tc.rst

@@ -36,7 +36,7 @@ basin
 Specify a comma-separated list of basins to be used. Expected format is
 a 2-letter basin identifier. An empty list indicates that all should be used.
 
-|  Valid basins: WP, IO, SH, CP, EP, AL, SL
+|  Valid basins: "WP", "IO", "SH", "CP", "EP", "AL", "SL"
 |
 
 For example:
@@ -235,12 +235,12 @@ Specify whether special processing should be performed for interpolated model
 names ending in 'I' (e.g. AHWI).  Search for corresponding tracks whose model
 name ends in '2' (e.g. AHW2) and apply the following logic:
 
-* "NONE" to do nothing.
+* NONE to do nothing.
 
-* "FILL" to create a copy of '2' track and rename it as 'I' only when the
+* FILL to create a copy of '2' track and rename it as 'I' only when the
   'I' track does not already exist.
 
-* "REPLACE" to create a copy of the '2' track and rename it as 'I' in all
+* REPLACE to create a copy of the '2' track and rename it as 'I' in all
   cases, replacing any 'I' tracks that may already exist.
 
 .. code-block:: none
@@ -394,16 +394,16 @@ replaced with "val". This map can be used to modify basin names to make them
 consistent across the ATCF input files.
 
 Many global modeling centers use ATCF basin identifiers based on region
-(e.g., 'SP' for South Pacific Ocean, etc.), however the best track data
+(e.g., "SP" for South Pacific Ocean, etc.), however the best track data
 provided by the Joint Typhoon Warning Center (JTWC) use just one basin
-identifier 'SH' for all of the Southern Hemisphere basins. Additionally,
+identifier "SH" for all of the Southern Hemisphere basins. Additionally,
 some modeling centers may report basin identifiers separately for the Bay
-of Bengal (BB) and Arabian Sea (AB) whereas JTWC uses 'IO'.
+of Bengal (BB) and Arabian Sea (AB) whereas JTWC uses "IO".
 
 The basin mapping allows MET to map the basin identifiers to the expected
 values without having to modify your data. For example, the first entry
-in the list below indicates that any data entries for 'SI' will be matched
-as if they were 'SH'. In this manner, all verification results for the
+in the list below indicates that any data entries for "SI" will be matched
+as if they were "SH". In this manner, all verification results for the
 Southern Hemisphere basins will be reported together as one basin.
 
 An empty list indicates that no basin mapping should be used. Use this if
@@ -854,11 +854,11 @@ Where "job_name" is set to one of the following:
   specified using the "-line_type" and "-column" arguments.
   For TCStat, the "-column" argument may be set to:
 
-  * "TRACK" for track, along-track, and cross-track errors.
-  * "WIND" for all wind radius errors.
-  * "TI" for track and maximum wind intensity errors.
-  * "AC" for along-track and cross-track errors.
-  * "XY" for x-track and y-track errors.
+  * TRACK for track, along-track, and cross-track errors.
+  * WIND for all wind radius errors.
+  * TI for track and maximum wind intensity errors.
+  * AC for along-track and cross-track errors.
+  * XY for x-track and y-track errors.
   * "col" for a specific column name.
   * "col1-col2" for a difference of two columns.
   * "ABS(col or col1-col2)" for the absolute value.

docs/Users_Guide/ensemble-stat.rst

@@ -50,7 +50,7 @@ The relative position (RELP) is a count of the number of times each ensemble mem
 
 The ranked probability score (RPS) is included in the Ranked Probability Score (RPS) line type. It is the mean of the Brier scores computed from ensemble probabilities derived for each probability category threshold (prob_cat_thresh) specified in the configuration file. The continuous ranked probability score (CRPS) is the average the distance between the forecast (ensemble) cumulative distribution function and the observation cumulative distribution function. It is an analog of the Brier score, but for continuous forecast and observation fields. The CRPS statistic is computed using two methods: assuming a normal distribution defined by the ensemble mean and spread (:ref:`Gneiting et al., 2004 <Gneiting-2004>`) and using the empirical ensemble distribution (:ref:`Hersbach, 2000 <Hersbach-2000>`). The CRPS statistic using the empirical ensemble distribution can be adjusted (bias corrected) by subtracting 1/(2*m) times the mean absolute difference of the ensemble members, where m is the ensemble size. This is reported as a separate statistic called CRPS_EMP_FAIR. The empirical CRPS and its fair version are included in the Ensemble Continuous Statistics (ECNT) line type, along with other statistics quantifying the ensemble spread and ensemble mean skill.
 
-The Ensemble-Stat tool can derive ensemble relative frequencies and verify them as probability forecasts all in the same run. Note however that these simple ensemble relative frequencies are not actually calibrated probability forecasts. If probabilistic line types are requested (output_flag), this logic is applied to each pair of fields listed in the forecast (fcst) and observation (obs) dictionaries of the configuration file. Each probability category threshold (prob_cat_thresh) listed for the forecast field is applied to the input ensemble members to derive a relative frequency forecast. The probability category threshold (prob_cat_thresh) parsed from the corresponding observation entry is applied to the (gridded or point) observations to determine whether or not the event actually occurred. The paired ensemble relative freqencies and observation events are used to populate an Nx2 probabilistic contingency table. The dimension of that table is determined by the probability PCT threshold (prob_pct_thresh) configuration file option parsed from the forecast dictionary. All probabilistic output types requested are derived from the this Nx2 table and written to the ascii output files. Note that the FCST_VAR name header column is automatically reset as "PROB({FCST_VAR}{THRESH})" where {FCST_VAR} is the current field being evaluated and {THRESH} is the threshold that was applied.
+The Ensemble-Stat tool can derive ensemble relative frequencies and verify them as probability forecasts all in the same run. Note however that these simple ensemble relative frequencies are not actually calibrated probability forecasts. If probabilistic line types are requested (output_flag), this logic is applied to each pair of fields listed in the forecast (fcst) and observation (obs) dictionaries of the configuration file. Each probability category threshold (prob_cat_thresh) listed for the forecast field is applied to the input ensemble members to derive a relative frequency forecast. The probability category threshold (prob_cat_thresh) parsed from the corresponding observation entry is applied to the (gridded or point) observations to determine whether or not the event actually occurred. The paired ensemble relative frequencies and observation events are used to populate an Nx2 probabilistic contingency table. The dimension of that table is determined by the probability PCT threshold (prob_pct_thresh) configuration file option parsed from the forecast dictionary. All probabilistic output types requested are derived from this Nx2 table and written to the ascii output files. Note that the FCST_VAR name header column is automatically reset as "PROB({FCST_VAR}{THRESH})" where {FCST_VAR} is the current field being evaluated and {THRESH} is the threshold that was applied.
 
 Note that if no probability category thresholds (prob_cat_thresh) are defined, but climatological mean and standard deviation data is provided along with climatological bins, climatological distribution percentile thresholds are automatically derived and used to compute probabilistic outputs. 
 

docs/Users_Guide/masking.rst

@@ -178,4 +178,4 @@ In this example, the Gen-Vx-Mask tool will read the ASCII Lat/Lon file named **C
 Feature-Relative Methods
 ========================
 
-This section contains a description of several methods that may be used to perform feature-relative (or event -based) evaluation. The methodology pertains to examining the environment surrounding a particular feature or event such as a tropical, extra-tropical cyclone, convective cell, snow-band, etc. Several approaches are available for these types of investigations including applying masking described above (e.g. circle or box) or using the "FORCE" interpolation method in the regrid configuration option (see :numref:`config_options`). These methods generally require additional scripting, including potentially storm-track identification, outside of MET to be paired with the features of the MET tools. METplus may be used to execute this type of analysis.  Please refer to the `METplus User's Guide <https://metplus.readthedocs.io/>`_.
+This section contains a description of several methods that may be used to perform feature-relative (or event -based) evaluation. The methodology pertains to examining the environment surrounding a particular feature or event such as a tropical, extra-tropical cyclone, convective cell, snow-band, etc. Several approaches are available for these types of investigations including applying masking described above (e.g. circle or box) or using the FORCE interpolation method in the regrid configuration option (see :numref:`config_options`). These methods generally require additional scripting, including potentially storm-track identification, outside of MET to be paired with the features of the MET tools. METplus may be used to execute this type of analysis.  Please refer to the `METplus User's Guide <https://metplus.readthedocs.io/>`_.

docs/Users_Guide/mode.rst

@@ -57,6 +57,7 @@ An example of the steps involved in resolving objects is shown in :numref:`mode-
 
    Example of an application of the MODE object identification process to a model precipitation field.
 
+.. _mode-attributes:
 
 Attributes
 ----------

docs/Users_Guide/overview.rst

@@ -62,7 +62,7 @@ The Grid-Diag tool produces multivariate probability density functions (PDFs) th
 
 The Wavelet-Stat tool decomposes two-dimensional forecasts and observations according to the Intensity-Scale verification technique described by :ref:`Casati et al. (2004) <Casati-2004>`. There are many types of spatial verification approaches and the Intensity-Scale technique belongs to the scale-decomposition (or scale-separation) verification approaches. The spatial scale components are obtained by applying a wavelet transformation to the forecast and observation fields. The resulting scale-decomposition measures error, bias and skill of the forecast on each spatial scale. Information is provided on the scale dependency of the error and skill, on the no-skill to skill transition scale, and on the ability of the forecast to reproduce the observed scale structure. The Wavelet-Stat tool is primarily used for precipitation fields. However, the tool can be applied to other variables, such as cloud fraction.
 
-Results from the statistical analysis stage are output in ASCII, NetCDF and Postscript formats. The Point-Stat, Grid-Stat, Wavelet-Stat, and Ensemble-Stat tools create STAT (statistics) files which are tabular ASCII files ending with a ".stat" suffix. The STAT output files consist of multiple line types, each containing a different set of related statistics. The columns preceeding the LINE_TYPE column are common to all lines. However, the number and contents of the remaining columns vary by line type.
+Results from the statistical analysis stage are output in ASCII, NetCDF and Postscript formats. The Point-Stat, Grid-Stat, Wavelet-Stat, and Ensemble-Stat tools create STAT (statistics) files which are tabular ASCII files ending with a ".stat" suffix. The STAT output files consist of multiple line types, each containing a different set of related statistics. The columns preceding the LINE_TYPE column are common to all lines. However, the number and contents of the remaining columns vary by line type.
 
 The Stat-Analysis and MODE-Analysis tools aggregate the output statistics from the previous steps across multiple cases. The Stat-Analysis tool reads the STAT output of Point-Stat, Grid-Stat, Ensemble-Stat, and Wavelet-Stat and can be used to filter the STAT data and produce aggregated continuous and categorical statistics. Stat-Analysis also reads matched pair data (i.e. MPR line type) via python embedding. The MODE-Analysis tool reads the ASCII output of the MODE tool and can be used to produce summary information about object location, size, and intensity (as well as other object characteristics) across one or more cases.
 

docs/Users_Guide/point-stat.rst

@@ -23,7 +23,7 @@ Interpolation/Matching Methods
 
 This section provides information about the various methods available in MET to match gridded model output to point observations. Matching in the vertical and horizontal are completed separately using different methods.
 
-In the vertical, if forecasts and observations are at the same vertical level, then they are paired as-is. If any discrepancy exists between the vertical levels, then the forecasts are interpolated to the level of the observation. The vertical interpolation is done in the natural log of pressure coordinates, except for specific humidity, which is interpolated using the natural log of specific humidity in the natural log of pressure coordinates. Vertical interpolation for heights above ground are done linear in height coordinates. When forecasts are for the surface, no interpolation is done. They are matched to observations with message types that are mapped to **SURFACE** in the **message_type_group_map** configuration option. By default, the surface message types include ADPSFC, SFCSHP, and MSONET. The regular expression is applied to the message type list at the message_type_group_map. The derived message types from the time summary ("ADPSFC_MIN_hhmmss" and "ADPSFC_MAX_hhmmss") are accepted as "ADPSFC".
+In the vertical, if forecasts and observations are at the same vertical level, then they are paired as-is. If any discrepancy exists between the vertical levels, then the forecasts are interpolated to the level of the observation. The vertical interpolation is done in the natural log of pressure coordinates, except for specific humidity, which is interpolated using the natural log of specific humidity in the natural log of pressure coordinates. Vertical interpolation for heights above ground are done linear in height coordinates. When forecasts are for the surface, no interpolation is done. They are matched to observations with message types that are mapped to "SURFACE" in the **message_type_group_map** configuration option. By default, the surface message types include ADPSFC, SFCSHP, and MSONET. The regular expression is applied to the message type list at the message_type_group_map. The derived message types from the time summary ("ADPSFC_MIN_hhmmss" and "ADPSFC_MAX_hhmmss") are accepted as "ADPSFC".
 
 To match forecasts and observations in the horizontal plane, the user can select from a number of methods described below. Many of these methods require the user to define the width of the forecast grid W, around each observation point P, that should be considered. In addition, the user can select the interpolation shape, either a SQUARE or a CIRCLE. For example, a square of width 2 defines the 2 x 2 set of grid points enclosing P, or simply the 4 grid points closest to P. A square of width of 3 defines a 3 x 3 square consisting of 9 grid points centered on the grid point closest to P. :numref:`point_stat_fig1`  provides illustration. The point P denotes the observation location where the interpolated value is calculated. The interpolation width W, shown is five. 
 

docs/Users_Guide/reformat_point.rst

@@ -454,7 +454,7 @@ While initial versions of the ASCII2NC tool only supported a simple 11 column AS
 
 • `AirNow DailyData_v2, AirNow HourlyData, and AirNow HourlyAQObs formats <https://www.epa.gov/outdoor-air-quality-data>`_. See the :ref:`MET_AIRNOW_STATIONS` environment variable.
 
-• `National Data Buoy (NDBC) Standard Meteorlogical Data format <https://www.ndbc.noaa.gov/measdes.shtml>`_. See the :ref:`MET_NDBC_STATIONS` environment variable.
+• `National Data Buoy (NDBC) Standard Meteorological Data format <https://www.ndbc.noaa.gov/measdes.shtml>`_. See the :ref:`MET_NDBC_STATIONS` environment variable.
 
 • `International Soil Moisture Network (ISMN) Data format <https://ismn.bafg.de/en/>`_.