-
Notifications
You must be signed in to change notification settings - Fork 26
Feature #3132 openmp vx util #3136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…o most MET tools via regridding.
… threads that actually are available.
… in the vx_regrid library to avoid duplication.
… using stl::vector's instead of manual memory management. This required introducing a DataPlaneArray::at(int) accessor function. Modify some library and application code to get things compiling.
…ike apply_mask(). Doing so produced a Grid-Stat runtime failure.
…n all GHA tests more efficiently.
… parallelized regridding actually runs well and produces the expected output.
…nto feature_3132_openmp_vx_util
…runtime segfault in the unit_regrid.xml unit test.
…es that include break statements.
…he compilation.
… the maximum number of available threads. ci-run-unit
…nce that triggers a failure when ncdiff is used to compute differences: libgomp: Invalid value for environment variable OMP_NUM_THREADS ... ci-run-unit
…te unit_met_test_scripts.xml to add missing expected output file names. ci-run-unit
…uction(+:n) to avoid race conditions updating the counter. ci-run-unit
…rQube code smells.
@jprestop, FYI, I compiled this feature branch as the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JohnHalleyGotway I have carefully reviewed the changes in vx_util
. Thank you for meeting with me and answering my specific questions.
Upon a quick review for checking to see if there are any loops you missed that I'd recommend be parallelized, nothing jumped out at me.
I'll also note that with regard to "Recommend that we consider tweaking our SonarQube configuration to stop flagging #pragma lines.", we did just that in our meeting. We created a new Quality Profile "Sonar Way with Pragma" in order to deactivate "Nested code blocks should not be used" which is the rule (c:S1199) that "Extract this nested code block into a separate function" falls under. We set the MET Current Quality Profile to "Sonar Way with Pragma" and saw a reduction in code smells by the expected 17. I also confirmed that the overall number of SonarQube code smells was reduced by the number you indicated. Thanks for all of your work on this task.
@JohnHalleyGotway I'm working on this today. Sorry it's late! |
I have tested these changes using grid_stat to verify RRFS output with MRMS radar reflectivity. For reference, I used I did the same using The results are as follows:
Unfortunately, it doesn't seem that increasing |
Yikes! @briannen this is my fault. The code I asked you to test was ACTUALLY
That explains the lack of an improvement! I just fixed that by checking out the correct branch and recompiling. Are you able to retest? @briannen, FYI, I did find your test files on seneca and checked the timing of running Running Grid-Stat from the nightly build area takes about 6.3 seconds, while running it for my pull request takes about 5.8 seconds. And that modest runtime improvement of about 0.5 seconds is about what I'd expect based on the proposed changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JohnHalleyGotway I reran the tests and can confirm that the run time does improve.
- Reference run: 14.782s
- OMP reference runs
- 1 thread: 14.165s
- 2 threads: 10.305s
- 4 threads: 8.200s
- 8 threads: 7.175s
- 16 threads: 6.721s
- 32 threads: 6.488s
- 40 threads: 6.543s
- OMP reference runs
- PR test run: 14.523s
- OMP PR test runs
- 1 thread: 14.311s
- 2 threads: 9.925s
- 4 threads: 7.775s
- 8 threads: 6.574s
- 16 threads: 5.986s
- 32 threads: 5.954s
- 40 threads: 5.836s
- OMP PR test runs
Expected Differences
This PR is the second of multiple ones to enhance MET by expanding its use of OpenMP. This PR focuses on changes in the
vx_util
library and modifies 17 files:Some minor whitespace formatting tweaks that are self-explanatory.
In
test_env_var.sh
, stop hard-codingOMP_NUM_THREADS = 4
in case the GHA hardware improves to provide more threads.In
unit_met_test_scripts.xml
, add a couple of missing expected output file names.In
data_cube.h/.cc
, add parallelization and apply consistent formatting.In
data_plane.h/.cc
...#pragma omp for reduction(...)
to allow for parallelization when computing sums, mins, and maxes.DataPlane::set_times()
function to avoid redundant code.DataPlane::set_times()
fromvx_regrid.cc
,vx_regrid_budget.cc
, andgen_vx_mask.cc
.DataPlaneArray
dynamically-allocated memory using STL::vectors to satisfy SonarQube.DataPlaneArray::at()
function to provide a non-const reference to the array values to solve compilation issues.DataPlaneArray::at()
fromread_climo.cc
,ensemble_stat.cc
, andpoint_stat.cc
.In
handle_openmp.cc
, update the OMP_NUM_THREADS validation logic and refine log messages.In
interp_util.cc
, no parallelization changes but avoid dynamically-allocated memory to satisfy SonarQube.Do these changes introduce new tools, command line arguments, or configuration file options? [No]
If yes, please describe:
Do these changes modify the structure of existing or add new output data types (e.g. statistic line types or NetCDF variables)? [No]
If yes, please describe:
Pull Request Testing
Describe testing already performed for these changes:
Used GHA to verify that not changes to the output are introduced. However, I did not quantify runtime improvements.
Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
@jprestop please review the code changes in
vx_util
carefully. I focused on parallelizing loops over 2D grids of data (e.g. theDataPlane
class). You could check to see if there's any loops I missed that you'd recommend be parallelized as well. Please double-check that the overall number of SonarQube code smells are reduced.@briannen please do some performance testing, comparing to the develop branch AFTER
feature_3132_openmp_vx_regrid
was merged on 4/25/25. I'd recommend running Grid-Stat using RRFS input data to verify multiple fields and see if any runtime improvements are discernable.Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]
No additional doc updates needed.
Do these changes include sufficient testing updates? [Yes]
No additional testing updates needed.
Will this PR result in changes to the MET test suite? [No]
If yes, describe the new output and/or changes to the existing output:
I confirmed through GHA runs that no diffs are introduced.
Will this PR result in changes to existing METplus Use Cases? [No]
If yes, create a new Update Truth METplus issue to describe them.
No METplus diffs expected.
Do these changes introduce new SonarQube findings? [No]
If yes, please describe:
While code smells in "new code" are flagged, the overall number are reduced by 100, from 17,312 in develop to 17,212 for this PR. And I already addressed the easy ones flagged in the new code.
Note that SonarQube does complain about these code blocks:
With Extract this nested code block into a separate function.
Recommend that we consider tweaking our SonarQube configuration to stop flagging
#pragma
lines.Pull Request Checklist
See the METplus Workflow for details.
Select: Reviewer(s) and Development issue
Select: Milestone as the version that will include these changes
Select: METplus-X.Y Support project for bugfix releases or MET-X.Y Development project for the next coordinated release