DRAFT: Update to capgen-ng#695
Conversation
…dim-names to capgen call
There was a problem hiding this comment.
Ignore this, for my development only
Changes to get the SCM tests to run: * clm_lake was included in a SDF, but not used. In the Cap, there is a (new?) check to see if the active conditions are met before calling the scheme. This was causing a runtime error. CLM Lake returns if not turned on, so having this new runtime check beforehand triggered the failure before entering the scheme. I removed the unused CLM Lake from the SDF and it worked fine. * Remove GFS_v16_debug SDFs from test list. (I see these were removed from the CCPP SCM?) * Add snippet to ccpp/CMakeLists to build only requested SDFs (i.e., -DCCPP_SUITES). * Uncomment and test 32-bit and Intel oneAPI in CMakeLists.
…; fix metadata-fortran inconsistencies, fix GitHub actions take 1
|
@climbfuji Looks like most of the tests are B4B, the only exception are the GNU release (optimized) tests. Could this be from compilation flag changes (e.g., Adding -fPIC)? The differences appear to be rounding errors for the GFS based tests, whereas the HRRR_gf and WoFs tests show non-negligible differences. For example: Full set of difference plots are stored as artifacts here |
Thanks for doing this comparison. The NEPTUNE runs are also not b4b identical. I think this is predominantly because the caps look different and the compiler optimizes the code differently. But for the two suites you mentioned, what do they have in common that the other suites don't have? I am certain that the much stricter validator and code generator helped identify and fix a few actual bugs. |
|
@dustinswales @climbfuji GNU release RTs for the SCM have been changing results basically every PR. It seems like something is just not reproducible or otherwise fishy with the environment. I wouldn't base any decisions on whether GNU release tests are b4b or not. |
@grantfirl Thanks. I thought it was an odd result. In any event... I've seen enough to warrant trying capgen-ng in the UFS. Any objections @climbfuji? |
|
No objections at all, please go ahead. I can also help out if you share a working branch and/or a checkout on Ursa, for example. I expect we'll have to fiddle a bit with the physics called from the dycore ... |
|
@dustinswales @grantfirl Looks like we'll have a clean pass through all CI tests in a few minutes. |
|
@dustinswales @grantfirl I think this is good now. We've got the tendencies and C3 updates in this branch (updated today from main), and the tests all pass. |
@climbfuji Thanks for these bug fixes. |
3 participants
IGNORE - SNEAK PREVIEW FOR CCPP-SCM DEVELOPERS
Dependencies
##########################
SOURCE: Developer's name and affiliation
DESCRIPTION OF CHANGES:
scm/docif needed.ISSUE: # Enter GitHub Issue number after
#ASSOCIATED PRs:
TESTS CONDUCTED: List tests done as appropriate. Delete if not used.
This PR catches the NCAR:main branch up with changes from the ufs-community:ufs/dev branch.
Associated ufs/dev PR:
Associated ufsatm PR:
Associated NCAR PR:
REGRESSION TEST CHANGES: Enter NONE if not applicable. Otherwise, expected results changes, input data changes, changes to the software, etc.