Allow wave grid to be different than ocean/ice grid#1279
Allow wave grid to be different than ocean/ice grid#1279DeniseWorthen wants to merge 194 commits into
Conversation
|
I've done a test on cheyenne.intel to get an idea of how much difference a lower resolution wave model makes. I only changed the tripole resolution for the wave model, ocean and ice continue to run on the usual resolution. For the cpld_control_c192_p8 test (fhmax=30), I subbed in the mx100 tripole mesh and mod_def from the cpld_control_p8 run directory. I obtained the following time comparisons: c192mx050 : The total amount of wall time = 1477.676412 A similar comparison for cpld_bmark_p8 (fhmax=6) using the mx050 tripole mesh and mod_def from the cpld_control_c192_p8 test: c384mx025 : The total amount of wall time = 1691.170446 |
|
@DeniseWorthen do you have run directories that I could look at by chance? |
|
I just ran the full RTs on hera; two hafs jobs failed (which I was not expecting), so my run directories still exist. /scratch1/NCEPDEV/stmp2/Denise.Worthen/FV3_RT/rt_11753 You can copy from there and swap the mod_def and mesh that you want to use. The only configuration change you need to make is the name of the mesh file that the wave model uses in nems.configure. |
|
Thanks @DeniseWorthen I tried to use your branch with the workflow and it failed, but I assume it was a set-up issue on my end. I'll check when I get a chance. I'm also curious if maybe the waves is not the slowest component on these tests and if maybe the wave model is still speeding up even if overall time is not. I'll copy some of your directories and tests my theory. Thanks for sharing the rundirs! |
|
@DeniseWorthen I ran the ESMF profiler with the bencharmk and the c192 cases, I believe similar to what you ran and also found that the overall times were not huge changes, but looking at the wave model itself, there's huge speed ups (see /scratch1/NCEPDEV/stmp2/Jessica.Meixner/try_05/*/ESMF_Profile.summary) I'm going to try some 5 day runs from the workflow now and will report back. |
|
@JessicaMeixner-NOAA OK, sounds good. I think we need to be careful though because the timesteps set in the mod-def might not be appropriate for the faster coupling (ie, bmark runs fast loop runs at 300 vs c192 at 600). I thought the ww3 global timestep was set to the coupling frequency? |
|
@DeniseWorthen good point! I'll double check that now. The global time step does get over-written by the coupling time step, but likely might mean it's not optimal. |
* all tests using cmeps (s2s, hafs, cdeps) pass on cheyenne.intel
|
I did had an issue on Hera.intel (NOAA-EMC/hpc-stack#470) with creating the mesh file for the rectilinear 30m grid, but I was finally able to do it using the following two commands (and reverting to intel 18). The center grid points for the SCRIP file are -80:80 and 0:359.5. I tested this w/ the bmark configuration and it is not working. I will update here when I know more. |
|
I corrected the SCRIP generation; it needs to be generated as a regional domain, not global when using NCO. I've verified w/ this mesh file, the model will at least run. |
|
Closed via #1256 |
PR Checklist
This PR is up-to-date with the top of all sub-component repositories except for those sub-components which are the subject of this PR. Please consult the ufs-weather-model wiki if you are unsure how to do this.
This PR has been tested using a branch which is up-to-date with the top of all sub-component repositories except for those sub-components which are the subject of this PR
An Issue describing the work contained in this PR has been created either in the subcomponent(s) or in the ufs-weather-model. The Issue should be created in the repository that is most relevant to the changes in contained in the PR. The Issue and the dependent sub-component PR
are specified below.
Results for one or more of the regression tests change and the reasons for the changes are understood and explained below.
New or updated input data is required by this PR. If checked, please work with the code managers to update input data sets on all platforms.
Instructions: All subsequent sections of text should be filled in as appropriate.
The information provided below allows the code managers to understand the changes relevant to this PR, whether those changes are in the ufs-weather-model repository or in a subcomponent repository. Ufs-weather-model code managers will use the information provided to add any applicable labels, assign reviewers and place it in the Commit Queue. Once the PR is in the Commit Queue, it is the PR owner's responsibility to keep the PR up-to-date with the develop branch of ufs-weather-model.
Description
Provide a detailed description of what this PR does. What bug does it fix, or what feature does it add? Is a change of answers expected from this PR? Are any library updates included in this PR (modulefiles etc.)?
Issue(s) addressed
Testing
How were these changes tested? What compilers / HPCs was it tested with? Are the changes covered by regression tests? (If not, why? Do new tests need to be added?) Have regression tests and unit tests (utests) been run? On which platforms and with which compilers? (Note that unit tests can only be run on tier-1 platforms)
Dependencies