Speed up unit test build & run #869
Assignees
Comments
rljacob
pushed a commit
that referenced
this issue
Feb 8, 2017
… (PR #869) This merge updates the ocean model to a newer version which limits the amount of pressure that can be felt from the sea ice model in order to prevent evacuated ocean cells. Additional modifications are updating the default namelist and streams files for the ocean and sea ice models, along with adding the ne30_oRRS30to10 resolution as an option to the WCYCL compsets, and to update the mapping files for the ne30_oQU120 resolution. OG-492 [CC] * origin/douglasjacobsen/mpas-o/limited_ssp_and_default_configs: Update MPAS-O to include a limited sea ice surface pressure Add ne30_oRRS30to10 as a WCYCL compset, and update oQU120 mesh Update the default configurations for MPAS-O and MPAS-Seaice
|
@billsacks still relevant? |
|
Still possibly relevant but never gonna happen. |
|
(In practice, when I'm doing test-driven-development, after I do an initial build and run of the unit tests on a branch, I cd into the unit test build subdirectory for just the tests I'm working on and run something like 'make && make test' from there, so that I only end up rerunning the tests I'm currently working on. This works well for me, though is currently undocumented.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From @billsacks on December 21, 2015 23:21
The unit test build and run can take longer than I'd like. This is particularly true for CLM, which now has 20 unit test executables; each of these is linked against the CLM library, so whenever you change any CLM code, all 20 need to relink. So the build takes some time due to that. In addition, particularly on yellowstone, the use of mpi-based tests means that each test executable takes more than 1 sec to run, leading to a total test time of about 30 sec (these tests should run in milliseconds).
A few ideas about how to speed things up:
(1) Create a single test executable for all of CLM (or perhaps one executable for each CLM subdirectory - e.g., a biogeophys test executable, etc.). However, by itself, this is considered unacceptable, because CTest doesn't give granular enough reporting. So, would it be possible to have a single executable, with CTest calling it multiple times in different ways (as in http://baoilleach.blogspot.com/2013/06/using-ctest-with-multiple-tests-in.html)? Having a single executable would (a) speed up the build, (b) speed up the run, (c) make it easier to move around code and its associated tests.
(2) Revisit issue CESM-Development#26 : allow tests to use a serial build of pFUnit when possible. This would allow you to run CLM unit tests from yellowstone (rather than needing to do so on caldera), and would speed up the run time if (1) isn't feasible.
Copied from original issue: CESM-Development#341
The text was updated successfully, but these errors were encountered: