Fix merge conflict

.github/workflows/build_docker_and_trigger_metplus.yml

@@ -40,6 +40,7 @@ jobs:
                 repository: '${{ github.repository }}',
                 ref: '${{ github.ref }}',
                 actor: '${{ github.actor }}',
-                sha: '${{ github.sha }}'
+                sha: '${{ github.sha }}',
+                pusher_email: '${{ github.event.pusher.email }}'
               },
             });

met/data/config/GenEnsProdConfig_default

@@ -57,6 +57,13 @@ ens = {
    ];
 }
 
+//
+// IDs for ensemble members
+// Only set if processing a single file with all ensembles
+//
+ens_member_ids = [];
+control_id = "";
+
 ////////////////////////////////////////////////////////////////////////////////
 
 //

met/docs/Users_Guide/gen-ens-prod.rst

@@ -67,7 +67,7 @@ Required arguments gen_ens_prod
 Optional arguments for gen_ens_prod
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-4. The **-ctrl file** option specifies the input file for the ensemble control member. Data for this member is included in the computation of the ensemble mean, but excluded from the spread. The control file should not appear in the **-ens** list of ensemble member files.
+4. The **-ctrl file** option specifies the input file for the ensemble control member. Data for this member is included in the computation of the ensemble mean, but excluded from the spread. The control file should not appear in the **-ens** list of ensemble member files (unless processing a single file that contains all ensemble members).
 
 5. The **-log** file outputs log messages to the specified file.
 
@@ -134,6 +134,50 @@ For each dictionary entry in the **field** array, give the name and vertical or
 
 _______________________
 
+.. code-block:: none
+
+  ens_member_ids = [];
+  control_id = "";
+
+The **ens_member_ids** array is only used if reading a single file that contains all ensemble members.
+It should contain a list of string identifiers that are substituted into the **ens** dictionary fields
+to determine which data to read from the file.
+The length of the array determines how many ensemble members will be processed for a given field.
+Each value in the array will replace the text **MET_ENS_MEMBER_ID**.
+
+**NetCDF Example:**
+
+.. code-block:: none
+
+  ens = {
+    field = [
+      {
+        name  = "fcst";
+        level = "(MET_ENS_MEMBER_ID,0,*,*)";
+      }
+    ];
+  }
+
+**GRIB Example:**
+
+.. code-block:: none
+
+  ens = {
+    field = [
+      {
+        name     = "fcst";
+        level    = "L0";
+        GRIB_ens = "+MET_ENS_MEMBER_ID";
+      }
+    ];
+  }
+
+**control_id** is a string that is substituted in the same way as the **ens_member_ids** values
+to read a control member. This value is only used when the **-ctrl** command line argument is
+used. The value should not be found in the **ens_member_ids** array.
+
+_______________________
+
 .. code-block:: none
 
   nbrhd_prob = {

met/docs/Users_Guide/point-stat.rst

@@ -22,7 +22,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. 
+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.