Fix several small bugs in met-9.0.

[JohnHalleyGotway]

Describe the Problem

Several small issues have arisen in the last week for which bugfixes should be provided. For convenience I'm grouping them into one issue and pull request. The details are listed below:

(1) The Gerrity score (GER column of MCTS line type) has nan's (not-a-number) in the output, as reported by Julie Prestopnik for the RAL Skymet project. nan's are never acceptable in the output from the MET tools. They indicate that an illegal mathematical option was performed. MET should check for these and write a bad data value to the output instead.

(2) Specifying MAXGAUSS as an smoothing method in the interp dictionary of Grid-Stat results in this error message, as reported by Tina Kalb:

ERROR  : interp_gaussian_dp() -> the gaussian weights were not computed (max_r: 0).

MET should be fixed to support this smoothing method.

(3) The compilation of ascii2nc fails when not using the "--enable-python" configuration option, as reported by Hank Fisher when compiling for HWT.
In ascii2nc.cc, the include "global_python.h" line should be moved into the ifdef ENABLE_PYTHON block.

(4) Update the user’s guide:
The descriptions of the MED_FO and MED_OF statistics in Appendix C should be clarified, as reported by Sarah Griffin via met-help and confirmed by Eric Gilleland. See comments below.

Add note about desc[] to the TC-Gen section, as described in the comment below from Dan.

Expected Behavior

(1) nan's should never be written by MET.
(2) Grid-Stat should support the MAXGAUSS smoothing method.
(3) ascii2nc should compile with and without the --enable-python option.
(4) The documentation should be clarified.

Environment

Describe your runtime environment:
Various.

To Reproduce

Describe the steps to reproduce the behavior:
For issue (1):

1. Save the attached mctc.txt file containing a single MCTC output line from Point-Stat:
   mctc.txt

2. Run the following Stat-Analysis job:

stat_analysis -lookin mctc.txt -job aggregate_stat -line_type MCTC -out_line_type MCTS

3. Note the nan value in the output:

JOB_LIST:      -job aggregate_stat -line_type MCTC -out_line_type MCTS -out_alpha 0.05000
COL_NAME: TOTAL N_CAT     ACC ACC_NCL ACC_NCU ACC_BCL ACC_BCU      HK HK_BCL HK_BCU     HSS HSS_BCL HSS_BCU GER GER_BCL GER_BCU
    MCTS:   326     9 0.93865 0.90715 0.95994      NA      NA 0.21065     NA     NA 0.11063      NA      NA nan      NA      NA

For issue (2):
Run Grid-Stat using the MAXGAUSS method:

      {
         method = MAXGAUSS;
         width  = 11;
      }

For issue (3): Not necessary since Hank already confirmed that the proposed change fixes the compilation problem.

Relevant Deadlines

None.

Funding Source

None.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required (John Halley Gotway)
• Select scientist(s) or no scientist required (Eric Gilleland)

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Review projects and select relevant Repository and Organization ones
• Select milestone

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdb, METviewer, METexpress, METcalcpy, METplotpy
  No impacts.

Bugfix Checklist

See the METplus Workflow for details.

• Complete the issue definition above.
• Fork this repository or create a branch of master_<Version>.
  Branch name: bugfix_<Issue Number>_master_<Version>_<Description>
• Fix the bug and test your changes.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into master_<Version>.
  Pull request: bugfix <Issue Number> master_<Version> <Description>
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Complete the steps above to fix the bug on the develop branch.
  Branch name: bugfix_<Issue Number>_develop_<Description>
  Pull request: bugfix <Issue Number> develop <Description>
• Close this issue.

[JohnHalleyGotway]

Here's Eric's response via email:

It looks like the division by zero is happening because you only have one odds ratio over which to calculate the relative frequencies. Looking at Wilks' book on p. 274 to 275, it appears that the Gerrity score is defined only when you have at least two such relative frequencies. So, if you only have one, then it seems that NaN or NA would be a good response.

So I will update the Gerrity score computations to check for divide by zero and set Gerrity to bad data in that case.

[JohnHalleyGotway]

From Sarah Griffin:

Looking at the MET calculation, MED_FO is "from forecast to observation" and is calculated using the equation:
med_fo = (oy == 0 ? bad_data_double : med_fo_sum / oy);

Eric said 'In my paper, I always use the second letter to mean the "from" letter because that was how it was defined originally'. So, MED(A,B) is "from B to A". So, I'm assuming the MET explanation corresponds to MED(O,F). Therefore A=O and F=B.

MED(A,B) is calculated using the equation based on Gilleland (2017):
MED_equation
or from a more recent Gilleland (2020) (unpublished to my knowledge).
MED_calculation

Here's the confusion part.
MED_FO is "from forecast to observation". However, MED_FO averaged over OY in the MET code. That corresponds to MED(F,O) based on Eric's equations. Eric says that would define as "from observations to forecast" because 'the second letter means the "from" letter'. So the equation for MED_FO does not appear to match MET's description of MED_FO.

The reason I'm noticing this is I would like to calculate MED using objects for an upcoming paper. However, using Eric's equations and MET's DMAP netcdf output, I was getting the exact opposite of how I would interpret MET's DMAP text output. Assuming that "MED_OF = Mean-error Distance from observation to forecast", my calculation was giving me the value of MET_FO. That's consistent with the equation for med_fo, but not the description and creates confusion. If you would like to see my MED calculations, I've uploaded my data and files to the MET_help ftp.

[DanielAdriaansen]

@JohnHalleyGotway the omission from the documentation for TCGen section is on page 394 of the PDF located here:
https://dtcenter.org/sites/default/files/community-code/met/docs/user-guide/MET_Users_Guide_v9.0.1.pdf

On that page, the desc [] configuration file option is missing, and should come first after where filter [] is described. I think we can just copy the desc [] section from page 53 where the common MET config file options are described. Here's the text:

//
// The "desc" entry specifies a user-specified description for each verification
// task. This string is written to the DESC column of the ASCII output
// generated. It may be set separately in each "obs.field" verification task
// entry or simply once at the top level of the configuration file. If you're
// verifying the same field multiple times with different quality control
// flags, you should choose description strings (no whitespace) to distinguish
// between their output.
// e.g. desc = "QC_9";
//
desc = "NA";

Can you just review that the description of "desc" I copied from page 53 applies to TCGen?