Skip to content
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

Addition of coverage tool to unit tests in workflow #21

Merged
merged 21 commits into from
Jul 12, 2024

Conversation

fmalatino
Copy link
Contributor

@fmalatino fmalatino commented May 23, 2024

Description
Addition of coverage to unit tests in workflow to determine the scope of code touched by testing.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules
  • New check tests, if applicable, are included
  • Targeted model of this changed was triggered by a model need/shortcoming

@fmalatino fmalatino marked this pull request as ready for review May 23, 2024 15:25
bensonr
bensonr previously approved these changes May 24, 2024
oelbert
oelbert previously approved these changes May 25, 2024
xyuan
xyuan previously approved these changes May 25, 2024
Copy link

@xyuan xyuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we use more openmp threads to speed up the test?

mlee03
mlee03 previously approved these changes May 28, 2024
@fmalatino fmalatino dismissed stale reviews from mlee03, xyuan, oelbert, and bensonr via 5dced20 May 28, 2024 17:54
bensonr
bensonr previously approved these changes May 28, 2024
@@ -73,7 +74,7 @@ jobs:
export FV3_DACEMODE=BuildAndRun
export PACE_FLOAT_PRECISION=64
export PACE_TEST_N_THRESHOLD_SAMPLES=0
export OMP_NUM_THREADS=1
export OMP_NUM_THREADS=10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The OMP threading has been left untested for a great while. While I expect it will work, I'd rather have it done in another PR safety.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will roll back to OMP_NUM_THREADS=1, thank you both for pointing this out.

setup.py Outdated
@@ -16,7 +16,7 @@
]

test_requirements = ["pytest", "pytest-subtests", "serialbox"]
ndsl_requirements = ["ndsl @ git+https://github.com/NOAA-GFDL/NDSL.git@2024.04.00"]
ndsl_requirements = ["ndsl @ git+https://github.com/NOAA-GFDL/NDSL.git@develop"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad reference version.

Copy link
Collaborator

@FlorianDeconinck FlorianDeconinck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good start, we need to think further on what our time threshold is for those PR tests. Can you time how long this takes and we will add tests to see if we can cover a bigger section of the code.

Alternatively, we could run codecov to see how much is getting touch in pyFV3 and try to have stencil code coverage somewhere above the ~75% mark

@@ -73,7 +74,7 @@ jobs:
export FV3_DACEMODE=BuildAndRun
export PACE_FLOAT_PRECISION=64
export PACE_TEST_N_THRESHOLD_SAMPLES=0
export OMP_NUM_THREADS=1
export OMP_NUM_THREADS=10
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The OMP threading has been left untested for a great while. While I expect it will work, I'd rather have it done in another PR safety.

--which_modules=D_SW \
--threshold_overrides_file=./tests/savepoint/translate/overrides/standard.yaml \
./tests/savepoint
- name: Orchestrated dace:cpu Remapping
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the bare minimum for orchestration. We should probably run some pySHiELD code and the full FVDynamics case as well

Copy link
Contributor Author

@fmalatino fmalatino May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As of commit 453e6b7 the omp threads have been rolled back to 1, the NDSL version is back at 2024.04.00, and added coverage to the test suite. I timed the current test suite to take 5601.23 s (~93.35 mins). Would it make sense to add in the pySHiELD code and FVDynamics case in another PR?

Coverage result:

Name                                                       Stmts   Miss Branch BrPart  Cover
--------------------------------------------------------------------------------------------
pyFV3/_config.py                                             281     42     84      2    80%
pyFV3/dycore_state.py                                        120     39     52      1    64%
pyFV3/initialization/analytic_init.py                         20     11      6      0    35%
pyFV3/initialization/init_utils.py                           139     92     12      0    31%
pyFV3/initialization/test_cases/initialize_baroclinic.py      89     67      4      0    24%
pyFV3/initialization/test_cases/initialize_tc.py             164    164      2      0     0%
pyFV3/stencils/a2b_ord4.py                                   252    125     98     12    47%
pyFV3/stencils/c_sw.py                                       174    120     68      3    24%
pyFV3/stencils/d2a2c_vect.py                                 252    136    112      8    39%
pyFV3/stencils/d_sw.py                                       323    132    140     18    51%
pyFV3/stencils/del2cubed.py                                   90     45     40      0    36%
pyFV3/stencils/delnflux.py                                   252    129    155      8    37%
pyFV3/stencils/divergence_damping.py                         201     68     74      7    57%
pyFV3/stencils/dyn_core.py                                   277    122    114     11    46%
pyFV3/stencils/fillz.py                                       78     57     50      0    21%
pyFV3/stencils/fv_dynamics.py                                188    145     80      0    18%
pyFV3/stencils/fv_subgridz.py                                377    331     90      0    14%
pyFV3/stencils/fvtp2d.py                                      83     16     24      2    74%
pyFV3/stencils/fxadv.py                                      141     81     66      3    30%
pyFV3/stencils/map_single.py                                  59     21     16      0    59%
pyFV3/stencils/mapn_tracer.py                                 24      1      8      2    91%
pyFV3/stencils/moist_cv.py                                    52     33     20      0    43%
pyFV3/stencils/neg_adj3.py                                   188    169    106      0     8%
pyFV3/stencils/nh_p_grad.py                                   51     22     10      0    48%
pyFV3/stencils/pe_halo.py                                     11      8     10      0    14%
pyFV3/stencils/pk3_halo.py                                    24     10     10      0    41%
pyFV3/stencils/ppm.py                                         40     26     20      0    30%
pyFV3/stencils/ray_fast.py                                    94     67     84      0    21%
pyFV3/stencils/remap_profile.py                              318    276    220      2    11%
pyFV3/stencils/remapping.py                                  173     77     88      8    41%
pyFV3/stencils/riem_solver3.py                                74     45     30      1    31%
pyFV3/stencils/riem_solver_c.py                               57     31     28      0    33%
pyFV3/stencils/saturation_adjustment.py                      525    400    200      1    30%
pyFV3/stencils/sim1_solver.py                                 77     64     58      0    11%
pyFV3/stencils/temperature_adjust.py                          18     13     10      0    18%
pyFV3/stencils/tracer_2d_1l.py                                94     71     36      0    21%
pyFV3/stencils/updatedzc.py                                   72     36     28      1    45%
pyFV3/stencils/updatedzd.py                                   84     31     24      1    54%
pyFV3/stencils/xppm.py                                       169    122     78      3    32%
pyFV3/stencils/xtp_u.py                                       35     27     16      0    24%
pyFV3/stencils/yppm.py                                       170    122     78      3    33%
pyFV3/stencils/ytp_v.py                                       35     27     16      0    24%
pyFV3/testing/map_single.py                                   15     15      2      0     0%
pyFV3/testing/translate_dyncore.py                            55      3     16      1    94%
pyFV3/testing/translate_fvdynamics.py                         81     52     24      0    30%
pyFV3/testing/validation.py                                   89     62     20      0    27%
pyFV3/utils/functional_validation.py                          31     25      4      0    17%
pyFV3/version.py                                               2      0      0      0   100%
pyFV3/wrappers/geos_wrapper.py                               275    275     32      0     0%
--------------------------------------------------------------------------------------------
TOTAL                                                       6493   4053   2563     98    33%

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

93 mins and we are only touching 33% of the code? That's... disappointing. Is the coverage report aggregating everything correctly since all the test are done one by one?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, this is very slow, could you try using more openmp threads?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OpenMP won't help, the execution is not slow part, the build is. Frank restricted to one rank test (e.g. testing the data generated on rank 0 instead of the entire cube) and that should take care of the slowness of the test overall

@FlorianDeconinck
Copy link
Collaborator

This will require a release of NDSL with a higher DaCe, which would solve the few lasting issues around enumerate

@fmalatino
Copy link
Contributor Author

Issue regarding code coverage logged in 22

@fmalatino fmalatino marked this pull request as draft July 1, 2024 19:07
@fmalatino fmalatino marked this pull request as ready for review July 9, 2024 19:10
@FlorianDeconinck
Copy link
Collaborator

This should b renamed right?

@fmalatino fmalatino changed the title Addition of dace:cpu orchestrated versions of unit tests in workflow Addition of coverage tool to unit tests in workflow Jul 9, 2024
@@ -27,7 +27,7 @@

setup(
author="The Allen Institute for Artificial Intelligence",
author_email="[email protected]",
author_email="[email protected]",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to change any more of the information in the setup block such as python-requires and some of the other classifiers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the python-requires will wait for opinions of others to make subsequent changes.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't expect to release the code on pypi, this has minimal impact since most of that metadata is made for pypi and other tools that automate gathering informations on the packages.

That said, no reason to not change the other field to shift things to NOAA, correct license and Py 3.11 as a base py

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to change this (we should) we should change it everywhere so there is no inconsistency

Copy link
Collaborator

@oelbert oelbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Change to setup.py probably belongs in another PR where we revise all author info, but otherwise good to go

@fmalatino fmalatino merged commit 595c3c8 into NOAA-GFDL:develop Jul 12, 2024
4 checks passed
@romanc romanc mentioned this pull request Nov 12, 2024
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants