Physics changes for new ccpp framework (Capgen)

[dustinswales]

This PR contains changes needed for the next-generation ccpp-framewok, Capgen.

Most of the changes here relate to reordering the metadata to match the source argument list (Ordering in metadata files matters with Capgen!) However, there are other changes included here:

• Correct Fortran/Metadata mismatches. Capgen parses the source files and metadata files, creates header tables for both, and compares them. Prebuild only parsed the metadata files, so with Capgen we are catching quite a few inconsistencies (e.g. mismatches in argument intent and type)

• Adding CCPP metadata headers for all CCPP entry points. Some schemes had initialization/finalize phases in their meta files, but are missing CCPP argument tables in their source files. This wasn't causing any problems since these init/final schemes weren't doing anything, but this was a bug.

• LSM control flags. In Prebuild, the CCPP API provides the Group Caps a DDT with all the interstitial data, which is referenced in the call lists to the Schemes. In Capgen, the CCPP API provides flat fields to the Group Caps, which are referenced directly in the Scheme call lists. For example, Group calls to the noah lsm:

use lsm_noah, only: lsm_noah_run
In Prebuild Caps:
call lsm_noah_run(..., lsm_noah=physics%Model%lsm_noah, ...)
In Capgen Caps:
call lsm_noah_run(..., lsm_noah=lsm_noah, ...)

In Capgen, we have a conflict between a local variable name and the module name, lsm_noah, whereas this wasn't an issue with Prebuild since the local variable was referenced in the caps as part of its parent DDT.
While this is a new tiny limitation of Capgen wrt Prebuild, it is consistent with the fortran standard.

@climbfuji @grantfirl @mkavulich I am still working through some issues with Capgen in the SCM, but these physics changes have been stable for sometime now, and they "shouldn't" change the results. I haven't tested these changes in the UFS fork.

[climbfuji]

Thanks for making the MPI_Comm changes. I am still not sure how we want to test this. Did you decide if you want to take this to the UFS first for testing, or keep it here for testing with SCM, and then test in the UFS? Will the changes here work with ccpp_prebuild.py or do they require updating the framework at the same time (much more difficult to test)?

[dustinswales]

@climbfuji I've tested these changes with the SCM using Prebuild and they are B4B. I still need to test with the UFS.
@grantfirl If I'm going to test in with the UFS, I might as well close this PR down and move this into the ufs/dev fork? Then this can follow our typical UFS-fork-> Root route. Thoughts?

[dustinswales]

@grantfirl @DomHeinzeller This has gone stale and will need to be updated. However, the main (invasive) changes contained here are to the metadata ordering, which will not be needed with NCAR:ccpp-framework#666.

Closing this Draft PR.
Will open new PR later.