-
Notifications
You must be signed in to change notification settings - Fork 251
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
Add p7a test using tiled FV3 Fix files, P7a ICs and NoahMP; add open-water normalization in CMEPS (#549) #585
Add p7a test using tiled FV3 Fix files, P7a ICs and NoahMP; add open-water normalization in CMEPS (#549) #585
Conversation
Machine: cheyenne |
@BrianCurtis-NOAA I don't see the problem w/ the cheyenne-gnu. Could you take a look? |
Yeah, i'll look now |
Machine: gaea |
@BrianCurtis-NOAA There seems to have been a large BL creation failure which was not caught. If I look at the log here /lustre/f2/pdata/ncep/emc.nemspara/autort/pr/647735813/20210524150013/ufs-weather-model I can see that none of the S2S apps were actually compiled (I don't know why). But it didn't find this as a failure, so none of the jobs were marked as 'failed'. The script moved the baselines into place, but only from rt_069 and higher. Unfortunately, since it seems the test was a 'pass', the run directory was removed ( /lustre/f2/scratch/emc.nemspara/FV3_RT/rt_26151)? I can see some baselines present in the baseline directory. But when it tried to run the verify and a lot more jobs failed---again, not sure why but most seem to be because the baseline was missing. I'm concerned that there is a disk quota issue, since there are a lot of rt_ directories (some from March) here: /lustre/f2/scratch/emc.nemspara/FV3_RT I'm going to delete the oldest of them and try to run manually. |
I do not currently confirm that the move of files from REGRESSION_TEST_<compiler> to the baseline storage area was successful once the command is issued to do so. This leaves the potential for a disk quota issue to arise if the baseline storage area is getting full or is full without the code complaining of anything. This is good to know so I can implement such a check in my autort development. |
All RTs have completed successfully. We're ready for merge after run-ci completes and CMEPS is merged. |
Orion initial failed tests, PR 585: Auto-BL was successful (develop-20210524) cpld_control_wave: err log shows 0: slurmstepd: error: *** STEP 2110073.0 ON Orion-19-19 CANCELLED AT 2021-05-23T16:52:24 *** cpld_controlfrac_c384: err log shows 0: in fcst run phase 2, na= 168 cpld_restart_bmarkfrac: err log shows 113: forrtl: severe (174): SIGSEGV, segmentation fault occurred fv3_rrfs_v1beta: test ran, but all comparisons failed. Repeating the RT against same baseline allowed gave PASS cpld_bmarkfrac_v16: test ran, but all comparisons failed. Repeating the RT against the same baseline gave PASS |
* Add option for fv3gfs_aqm * Change parameter name
PR Checklist
Ths 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.
If new or updated input data is required by this PR, it is clearly stated in the text of the PR.
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 responsiblity to keep the PR up-to-date with the develop branch of ufs-weather-model.
Description
fv3_conf/cpld_bmark_tiled_run.IN
to use tiled FV3 fix filesBM7_IC
inFV3_input_frac
for the 8 initial condition dates. The input for 20140301 is used in the regression testcpld_bmarkfrac_wave_v16_noahmp
. The remaining dates can be used withrt_35d.conf
.input.benchmark_v16.nml.IN
to use configurable variables to implement either original v16 (P6) settings or v16 (P7a) settingscpld_bmarkfrac_wave_v16_noahmp
andcpld_bmarkfrac_wave_v16_noahmp_nsst
tests. Thensst
test is not added to rt.confNew input data is required:
FV3_fix_tiled
andFV3_input_frac/BM7_IC
. These have been added to the exisitinginput-data-20210518
on Hera and from there to the remaining platforms.The
FV3_fix_tiled
contains the contents of the directory:/scratch1/NCEPDEV/global/Helin.Wei/save/fix_sfc
. The subdirectories from this directory were re-named, e.g.sfc.C96
was renamed to justC96
.The
FV3_input_frac/BM7_IC
contains the contents of the directory:/scratch2/NCEPDEV/stmp3/Bing.Fu/o/p7ic/com/gens/dev/merge/C384_025
. The subdirectory nameC384
was renamed toC384_L127
to match the current RT directory structure.Issue(s) addressed
Fixes issue #582
Fixes issue #366
Testing
Without the aofrac normalization, On hera.intel and gaea.intell, all existing coupled baselines passed against the develop-20210513 after the additional input data was added. New baselines will be required for the new
cpld_bmarkfrac_wave_v16_noahmp
test.Updating this PR to include open water normalization in CMEPS will change all coupled baselines
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
If testing this branch requires non-default branches in other repositories, list them. Those branches should have matching names (ideally).
CMEPS PR #44