DRAFT (NOT READY FOR REVIEW) Feature/capgen

[dustinswales]

SOURCE: Developer's name and affiliation

DESCRIPTION OF CHANGES:

• Bullet points or paragraphs describing problem, solution, and required changes.
• Update documentation under scm/doc if needed.

ISSUE: # Enter GitHub Issue number after #

ASSOCIATED PRs:

• NCAR/ccpp-physics#
• NCAR/ccpp-framework#

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:

• ufs-community/ccpp-physics#

Associated fv3atm PR:

• NOAA-EMC/fv3atm#

Associated NCAR PR:

• NCAR/ccpp-physics#

---

REGRESSION TEST CHANGES: Enter NONE if not applicable. Otherwise, expected results changes, input data changes, changes to the software, etc.

[grantfirl]

@dustinswales It's possible that we can cut the number of suites in half for the SCM by implementing the prescribed surface fluxes differently (as discussed in past meetings). Basically, we'd change all suites to run through the surface calculations, but insert a group end after the surface schemes to return back to the SCM code to either replace the surface fluxes or use the ones calculated in physics. This might be a good opportunity to clean this up (and we can implement the 'beta' surface forcing method at the same time).

This would at least speed up capgen by reducing the number of suites organically, although it isn't necessarily a long term solution because we'd like to be able to use as many suites as necessary for SCM RTs since it's at least faster and less computationally intensive than UFS!

[dustinswales]

@dustinswales It's possible that we can cut the number of suites in half for the SCM by implementing the prescribed surface fluxes differently (as discussed in past meetings). Basically, we'd change all suites to run through the surface calculations, but insert a group end after the surface schemes to return back to the SCM code to either replace the surface fluxes or use the ones calculated in physics. This might be a good opportunity to clean this up (and we can implement the 'beta' surface forcing method at the same time).

This would at least speed up capgen by reducing the number of suites organically, although it isn't necessarily a long term solution because we'd like to be able to use as many suites as necessary for SCM RTs since it's at least faster and less computationally intensive than UFS!

@grantfirl I support the idea of getting rid of the _ps SDFs. I think I follow what you are proposing.
Since the SCM calls the whole CCPP API, we would need to modify the SCM to call the physics Groups directly? allowing us to apply logic between the physics Group calls? Do I understand correctly?