Update the EnsembleStat_fcstICAP_obsMODIS_aod use case to create meaningful output

[j-opatz]

Describe the Task

It was discovered in a recent run of the EnsembleStat_fcstICAP_obsMODIS_aod air quality and composition use case that output files were empty. The use case is successfully running, but due to a mismatch of how many ensemble members EnsembleStat is expecting (7) versus how many it actually receives (4), no output is created. The discrepancy is due to the input file (which contains all of the ensemble members) only containing 4 members with valid data; the remaining 3 only contain bad data.

This should be rectified fairly easily with a change to the number of ensemble members read in (0 to 3) and a change to the number of ensembles the tool should expect (4).

However, this raises a more important question of if the logic behind EnsembleStat needs to be adjusted for this situation. Currently, if EnsembleStat were to be passed 7 paths to files containing single ensemble members but 3 of those files did not exist, the use case would produce output. However, this use case's situation results in no output. These seem like the same issue with different outcomes, which should not be the case.

The logic in the line of code that controls EnsembleStat output requires that n_vld == n_ens. In ensemble_stat.cc, fcst.vld_thresh value is used (and stored as vld_data_thresh) when deriving ensemble-probability values. So if you don’t have enough valid data, you don’t derive a probability and EnsembleStat would rather produce no output than statistics based on a ensemble ranking that is nonsensical.

Time Estimate

1 hour

Sub-Issues

Consider breaking the task down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Review default alert labels
• Select component(s)
• Select priority
• Select requestor(s)

Milestone and Projects

• Select Milestone as a METplus-Wrappers-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
• For a METplus-Wrappers-X.Y.Z version, select the METplus-Wrappers-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Task Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Add any new Python packages to the METplus Components Python Requirements table.
• For any new datasets, an entry to the METplus Verification Datasets Guide.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Development issue
  Select: Milestone as the next official version
  Select: METplus-Wrappers-X.Y.Z Development project for development toward the next official release
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.