Optimization of ensemble_stat

[davidalbo]

Optimization of ensemble_stat

Describe the Enhancement

Explore the use of c++ pthread software to improve performance of ensemble_stat by adding threading

Time Estimate

20 hours

Sub-Issues

Consider breaking the enhancement down into sub-issues.

• Port existing threading code into the MET code base
• Examine ensemble_stat for potential bottlenecks and add threading to one or more such places
• Compare results with and without threading both for speed and for results

Relevant Deadlines

Early February 2025

Funding Source

2771024 (Air Force)

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 MET-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
• For a MET-X.Y.Z version, select the MET-X.Y.Z Development project

Define Related Issue(s)

Consider the impact to the other METplus components.

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

Enhancement 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.
• 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: MET-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.

[davidalbo]

From JohnHG, putting these comments here regarding slight differences when using the intel compiler vs the gnu compiler:

Looks like these numbers very close to 0 are all showing up in the BCMSE column (#58) of the SSVAR line type.

And they show up on 19 of the 708 SSVAR lines:

grep SSVAR ./output/202205010000-gnu-develop/ensemble_stat_20220502_000000V.stat | wc -l
708
grep SSVAR ./output/202205010000-gnu-develop/ensemble_stat_20220502_000000V.stat | grep 'e-' | awk '{print $58}' | wc -l
19

MET does have a "comp_stat.sh" utility (that requires the right env vars being set), but it also flags these small diffs:

stat1: /d1/personal/dave/AF_Optimization/output/202205010000-gnu-develop/ensemble_stat_20220502_000000V.stat
stat2: /d1/personal/dave/AF_Optimization/output/202205010000-intel-develop/ensemble_stat_20220502_000000V.stat
ERROR: found 7 differences in row type SSVAR column BCMSE - max abs: 0.000000000000028422

But yes, definitely not a concern. I see in compute_stats.cc where we could tweak the logic to make these 0 in the output. And I note that we do already do this when computing the components of SEEPS, like on this line.

We could add 2 new lines to that file to handle this:

95 // Compute bias corrected mean squared error (decomposition of MSE)
96 cnt_info.bcmse.v = cnt_info.mse.v - (s.fbar - s.obar)*(s.fbar - s.obar);
+++ cnt_info.bcmse.v = (is_eq(cnt_info.bcmse.v, 0.0) ? 0.0 : cnt_info.bcmse.v);

338 cnt_info.bcmse.v = cnt_info.mse.v - (f-o)*(f-o);
+++ cnt_info.bcmse.v = (is_eq(cnt_info.bcmse.v, 0.0) ? 0.0 : cnt_info.bcmse.v);

I don't feel very strongly about this. I note that SSVAR is a pretty lightly used line type to my knowledge. If silencing these diffs makes development slightly easier, please feel free to include this in your feature branch.

I made these changes and the diffs between intel and gnu did go away, which makes it easier to test further changes under both compilers.