UFS-dev PR#42 #92
UFS-dev PR#42 #92
Conversation
* aqm init_concentrations=false * ATMAQ tests are 32BIT
* use the latest postxconfig-NT-fv3lam.txt to run ifi * rename postxconfig-NT-fv3lam-ifi.txt to postxconfig-NT-fv3lam-new.txt since it is, in fact, the new postxconfig-NT-fv3lam.txt * add lightning threat indexes to rrfs 13km tests * pass w to model & fixes to ccpp/physics changes * FV3: turn off lightning_threat by default since it allocates wgrs and passes w * do not output ltg*_max variables since they're all zeroes anyway because the 13km run cannot make enough graupel * FV3: missing `active = (lightning_threat_indices_enabled)` for wgrd * enable ltg*_max variables in diag_table_hrrr * alternative POSTAPP for C96 versions of regional configurations * rap & hrrr variants use POSTAPP=fv3lam_global * new tests for ifi on acorn * fix out-of-bounds access in upp calslr_roebbr * fix another out-of-bounds access and move a message to stdout
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
@dustinswales I looked through the associated develop PRs and didn't find much in terms of which RTs are expected to fail, and I haven't heard back from Sam for clues. I think that we have to depend on the develop PRs passing and getting merged and that they were OK with whatever baselines changed so as not to delay this. |
on-behalf-of @NCAR <dswales@ucar.edu>
|
Automated RT Failure Notification |
on-behalf-of @NCAR <dswales@ucar.edu>
|
Automated RT Failure Notification |
grantfirl
added
cheyenne-gnu-BL
cheyenne-intel-BL
and removed
cheyenne-gnu-BL
cheyenne-intel-BL
labels
on-behalf-of @NCAR <dswales@ucar.edu>
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
Automated RT Failure Notification |
|
@dustinswales The hafs_regional_atm_wav run failed on the verification step of the baseline creation, but I reran the test individually, and it passed. Do you think it is OK to merge without including a new successful Cheyenne/Intel log? I'd really not like to run another round of RTs, especially since things seem to fail randomly. |
|
@grantfirl I think it's fine. To be honest, I don't see an advantage of keeping the logs under version control, at least with the troubles we have on Cheyenne. |
|
@dustinswales I'm going to keep the diff in tests/fv3_conf/compile_qsub.IN_cheyenne while we work through these PRs to save some work. |
Identical to ufs-community#1642
Also contains changes from ufs-community#1656.
Contains changes from #91 until it is merged and this branch is updated.