Reduce wallclock time and/or PE count of some tests
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- fortran
- Domain
- testing
Research direction
Start with the listed aux_clm tests and their test configuration files, then inspect how each test sets PE layout and wallclock limits. Compare configured limits with the reported runtimes and try smaller layouts or shorter limits for the candidates identified. Done means the selected tests use appropriately reduced resources and still pass.
Written by the indexing model from the issue text.
Description
A few years ago, I went through the aux_clm test list and reduced the wallclock time and/or PE count of tests to get better turnaround of the aux_clm test list. Since then, some tests have been added that have either longer-than-needed wallclock time, large PE counts, or both.
From a recent run of aux_clm on derecho, these are the tests still stuck in the queue and my suggestion for how to improve test turnaround:
Best candidates for improvement:
- ERS_D.f19_g17.I1850Clm50BgcCrop.derecho_intel.clm-ciso_monthly_matrixcn_spinup
- Can this be moved to lower resolution?
- If not, then use a smaller PE layout; I believe my goal a few years ago was to have all aux_clm tests fit in 4 nodes or less to get better turnaround time (the slower run time is usually worth it for the faster turnaround time); I suggest trying 1, 2 or 4 nodes (
_PSfor f19_g17 gives 1 node, so that's probably a good place to start). - Also reduce wallclock time from 1 hour 20 min to something much smaller (currently takes 4 minutes)
- PEM_D_Ld5.ne30_g17.I2000Clm50Bgc.derecho_intel.clm-default
- Can this be moved to lower resolution?
- If not, then use a smaller PE layout; I believe my goal a few years ago was to have all aux_clm tests fit in 4 nodes or less to get better turnaround time (the slower run time is usually worth it for the faster turnaround time); I suggest trying 1, 2 or 4 nodes
- Also reduce wallclock time from 1 hour to something much smaller (currently takes 5 minutes)
- REP_P64x2_Ld13.f10_f10_mg37.IHistClm60Bgc.derecho_intel.clm-monthly--clm-matrixcnOn_ignore_warnings
- Reduce wallclock time from 2 hours to something like 10 minutes (currently takes 2 minutes)
- ERP_P64x2_Ld396.f10_f10_mg37.IHistClm60Bgc.derecho_intel.clm-monthly--clm-matrixcnOn_ignore_warnings
- Reduce wallclock time from 2 hours to something like 20 - 30 minutes (currently takes 12 minutes)
There may not be much that can be done about these:
- ERS_Ly5_P128x1.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput
- Could reduce wallclock time slightly, from 2 hours to something like an hour or a little more (currently takes 47 minutes)
- But there may not be much that can be done about this one
- ERS_Ly5_P128x1.f10_f10_mg37.IHistClm60BgcCrop.derecho_intel.clm-cropMonthOutput--clm-matrixcnOn_ignore_warnings
- Could reduce wallclock time slightly, from 2 hours to something like an hour or a little more (currently takes 52 minutes)
- But there may not be much that can be done about this one
- SMS_Ly2_PS.f19_g17.I2000Clm60BgcCrop.derecho_intel.clm-cropMonthOutput
- Could reduce wallclock time slightly, from 2 hours to a little over an hour (currently takes 57 minutes)
- But there may not be much that can be done about this one
- Dominant language
- Fortran
- Stars
- 352
- Forks
- 365
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 13
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ESCOMP/CTSM
-
Indicate why we have two variables for snow cover fraction (frac_sno_albedo and frac_sno_fluxes) and when they are different.Possibly taken @olyson claimed this 18 days ago. Openb4b docs-loc:tech-note documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ESCOMP/CTSM#4219 · 1 comment · 2 assignees ·
Maintainers usually reply within 1 day
-
Change "Spinup" compsets to "Cplhist"Possibly taken @slevis-lmwg claimed this 18 days ago. Openb4b usability
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
ESCOMP/CTSM#4218 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
-
Only test CISM with the latest CLM physics (currently clm6_0)May be free again @ekluzek claimed this 40 days ago, and no pull request is open. Openb4b testing
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ESCOMP/CTSM#4168 · 2 comments · 2 assignees ·
Maintainers usually reply within 1 day
-
bug non-b4b science
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ESCOMP/CTSM#4119 · 4 comments ·
Maintainers usually reply within 1 day
-
b4b code health priority: low size: small
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
Similar issues
-
bug code-review testing tooling
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
good first issue tests
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
SimonWaldherr/golang-examples#109 ·
-
test-net.lua fails on linuxPossibly taken @PatrickDahlin claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
from-review-extraction python severity:nit testing
Difficulty 1/5 Under an hour Newbie friendliness 82/100
LearningCircuit/local-deep-research#7950 ·
Maintainers usually reply within 2 days