UFS-dev PR#53 #91
UFS-dev PR#53 #91
Conversation
…ces and turning off output; update FAQ documentation (was 1608); update drag suite intent mods (was 1612) (ufs-community#1597) * update cdeps * use fv3atm from PR 1612 * Changed UGWP diagnostic variable declaration intents from out to inout * Docs/faqupdate (NCAR#8) Co-authored-by: Denise Worthen <denise.worthen@noaa.gov> Co-authored-by: jkbk2004 <jong.kim@noaa.gov> Co-authored-by: Brian Curtis <brian.curtis@noaa.gov>
* MOM6 writes restarts in YYYYMMDD.HHMMSS.MOM*nc format * the final restart is timestamped * make changes in scripts to remove 'suffix-hours' strings * remove STORE_CORIOLIS from MOM_input templates * add timestamp in the end forecast restart filenames for GFS * FV3atm restart filename format
* Update FV3 * Merge pull request NCAR#67 from dustinswales/accumulated_cleanup * Updated physics * Reverting DISKNM/gaea to original * add new BL_DATE
…1578) * Faster Compile option turned on for a compile and test per project * added sample tests from each project to be tested with faster compile * HAFS app to be compiled with 64bit
…ble usage of shared pio (ufs-community#1645) * Gaea system: change in hpc-stack location, miniconda3 (EPIC-managed) * move DISABLE_FMA to one if at the end * only disable fma on wcoss if FASTER=ON * Update CMakeModules to develop; remove STATIC requirement from PIO find. Co-authored-by: Natalie Perlin <Natalie.Perlin@noaa.gov> Co-authored-by: ulmononian <cameron_book@alumni.brown.edu>
* fix clock initialization for a restart in WW3 * update WW3 submodule * update to develop WW3
…le pointer update for ufs-community#462 (ufs-community#1654) * update FV3 submodule and .gitmodules for testing of 20230313_combo * turn off cpld_control_p8_faster cheyenne
|
No changes to baselines expected due to ufs-community#1658 directly. |
|
Failed tests expected from ufs-community#1599 FAILED TESTS: FAILED TESTS: |
|
For ufs-community#1645 (shouldn't show up on Hera and Cheyenne RTs): Changes are expected to the following tests: hafs_regional_storm_following_1nest_atm_ocn_wav on WCOSS2 and Acorn only. |
|
@dustinswales Can I go ahead and add RT labels for this to verify failed tests? |
Do it. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
@dustinswales I'm not sure what to make of the cheyenne/intel failures. Does this message mean that the new baselines were created but that the tests against the new baseline failed (which might signal a reproducibility problem)? |
|
@grantfirl Ugh, I'm not sure what's going on here... In /glade/scratch/epicufsrt/GMTB/ufs-weather-model/RT/auto_RT/Pull_Requests/1298023507/20230405113544/ufs-weather-model/tests/RegressionTests_cheyenne.intel.log there are some conflicting pieces of information. At the end of the file it says the REGRESSION TEST WAS SUCCESSFUL, but at the top of the file there is a compilation fail for compile 008? Then in /glade/scratch/epicufsrt/GMTB/ufs-weather-model/RT/auto_RT/Pull_Requests/1298023507/20230405132802/ufs-weather-model/tests/RegressionTests_cheyenne.intel.log there are failures when comparing to the baselines? As you pointed out, this suggests reproducibility problems, but there shouldn't be? |
|
Automated RT Failure Notification |
|
@dustinswales I manually ran the hafs_regional_atm_ocn test against the baseline and it failed again. I'd sorta like to recreate the cheyenne intel baselines and see if the same error happens. Could you delete |
|
@grantfirl I just deleted /glade/scratch/epicufsrt/GMTB/ufs-weather-model/RT/NCAR/main-20230403/INTEL. |
|
Automated RT Failure Notification |
|
@dustinswales FWIW, I manually ran rt.ncar.sh on the hafs_regional_atm_ocn test using the -c and then the -m option, creating a new local baseline and checking against it, and it was successful. So, I'm guessing that this is a glitch? It looks like the compile_008 error above is a time-out. I'm fairly confident that we should be able to merge this, but we do need the BL creation to succeed so that we can test future PRs. |
|
The compilation timeout is using this line in rt.conf: I'm going to set the walltime in compile_qsub.IN_cheyenne to a larger number temporarily to see if it will pass. |
|
Looks like compile_008 takes ~33 minutes to run for future reference. |
|
@grantfirl Good sleuthing! I wonder why we are having timeout issues on cheyenne intel, but not on the UWM side? |
on-behalf-of @NCAR <dswales@ucar.edu>
|
Automated RT Failure Notification |
|
@dustinswales Please review/approve NCAR/ccpp-physics#1006, NCAR/fv3atm#88, and this so that we can merge. All tests completed. The failed tests on cheyenne.intel was a wild goose chase. |
…ng PR#1863) (ufs-community#1844) * Changes to logging and initialization of the CLM Lake Model. * merge ccpp-physics NCAR#91 (UFS-SRW v3.0.0 SciDoc updates) 1. Use ice thickness hice(i) to find the level in the lake where ice is zero. 2. Do not allow lake temperature to be below freezing point if there is no ice. 3. If there is no snow or ice, do not allow surface lake temperature to be below freezing point. These changes fixed the problem with large errors in the energy budget at the beginning of the cold-start run with lakes. 4. Added flag to turn on debug print statements in the CLM lake model. * explicitly turn of frac_ice for flake * t_grnd(i) should be t_grnd(c) ------------------------------------------------------------------- Co-authored-by: Samuel Trahan <samuel.trahan@noaa.gov> Co-authored-by: Grant Firl <grant.firl@noaa.gov>
Identical to ufs-community#1654
Also contains changes from ufs-community#1597, ufs-community#1599, ufs-community#1578, ufs-community#1645, ufs-community#1625, and ufs-community#1547