Enhance Grid-Stat to use OpenMP for efficient computation of neighborhood statistics by setting $OMP_NUM_THREADS

[mo-mglover]

Describe the New Feature

OpenMP provides a simple way of adding shared-memory (on-node) parallelism to serial code. It can be added incrementally, and can provide quick wins when a code has a few dominant hotspots.

The fractional_coverage routine in data_plane_util.cc contains a loop-nest representing one such hotspot. We aim to parallelize this loop with OpenMP. This would distribute loop iterations across multiple cores and pull down the overall time spent in GridStat.

OMP is directive-based. The directives begin with the comment character (!) and hence are ignored by the compiler if OpenMP support is not requested. To instruct the compiler to interpret OMP directives, an additional flag is normally required. This varies between compilers. With gfortran the flag is -fopenmp.

The number of threads can be controlled programmatically. However, it is sufficient to set environment variable OMP_NUM_THREADS at runtime.

Acceptance Testing

List input data types and sources.

The code should give identical answers with 1 vs. 2+ threads. A 1-thread vs. 2-thread result comparison would be needed. Small differences can sometimes appear with/without OpenMP compiled in (even with 1 thread only) because serially optimising compilers sometimes make different choices when the OpenMP flag is present. I don't think that's a reason to omit an OpenMP vs. no-OpenMP test, though; just something to be aware of. It is certainly possible to introduce bugs with OpenMP and only one thread, so OMP/no-OMP tests would be wise.

Time Estimate

Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.

Sub-Issues

Consider breaking the new feature down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

2799991

Define the Metadata

Assignee

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

Labels

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

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

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

New Feature 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 Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[mo-mglover]

Updated the scaling test slides with later results (last couple of slides). New results based off v10.1.0-beta4.

grid-stat-omp-scaling.pdf

[JohnHalleyGotway]

@mo-mglover I'm reading about the AC_OPENMP macro for Autoconf at this location. Seems like we should leverage this existing macro in configure.ac rather than a doing it in a custom way. FYI, I'm investigating this now.