CCPP-compliant cnvc90 and initial version of HRRR Thompson MP

[climbfuji]

WORK IN PROGRESS:

(1) use CCPP-compliant cnvc90 scheme in NEMSfv3gfs

(2) initial version of HRRR Thompson MP (aerosol-aware) in CCPP

[climbfuji]

Update 20180525:

New functionality that runs all scheme _init routines as part of ccpp_physics_init after an optional/additional init routine XXX specified as XXX in the SDF. For XXX, only the XXX_run function is used (it doesn't make sense to run an _init routine of a special initialization scheme). Similarly, all scheme _finalize routines are run as part of ccpp_physics_finalize, before an optional/additional finalize routine YYY specified as YYY in the SDF. For YYY, only the YYY_run function is used (it doesn't make sense to run a _finalize routine of a special finalization scheme).

The flow currently is:

init stage

XXX_run
all scheme_init

run stage

scheme_runs as before, all or selected groups or individually

finalize stage

all scheme_finalize
YYY_run

It can be argued if XXX_run should be after all scheme_init (YYY_run before all scheme_finalize), but in my opinion the current order makes more sense, since specialized init schemes (XXX) and finalize schemes (YYY) most likely have to prepare/cleanup stuff for/from the physics schemes.

[gold2718]

Using only XXX_run and YYY_run prevents use of a coordinated initialize / finalize sequence for a suite that is combined in one module.
Why not have <init>XXX</init> run XXX_init and <finalize>XXX</finalize> run XXX_final?
I believe this expanded flexibility will be useful.

[gold2718]

Is there any reason for the adjective / verb conflict between <init> and <finalize>?
How about <init> + <final>
or <initialize> + <finalize>?

[climbfuji]

@gold2718 ohh that's a good one. The original implementation had init and fini for all internal code in ccpp-framework, but requested init and finalize from the schemes. I made this consistent at least by changing fini to finalize. Since then, I was unhappy with having init (short) and finalize (long), so I very much like your idea of init and final as long as we do this for the ccpp-framework itself AND the ccpp physics schemes (requires updating a bit of documentation, but we would still be able to do that for the SCM-CCPP v2 release end of June).

EDIT: having said that, I would want to make this a separate, follow-up change for clarity.

[climbfuji]

I missed the second part of @gold2718 's comment, and I am not sure I understand it correctly.

For sure we can change that to running _init and _final(ize) instead of _run for the <init> and <finalize> blocks. That would allow using a single module=scheme for init and finalize, the _run routine wouldn't get used. This, however, would have the same effect as specifying this particular scheme in a separate group (call it "init_final") of the SDF and just leaving the _run routine empty.

But this also means that the special <init> and <finalize> aren't really needed, because one can always specify a scheme in this way,

my_special_init_and_final_scheme

that has an empty _run routine.

Looking at the extra lines of code for handling the <init> and <finalize> blocks, I am tempted to get rid of them because all the functionality we need is already there, and those extra blocks just create confusion.

Any comments? @gold2718 @grantfirl @ligiabernardet @llpcarson

[gold2718]

@climbfuji, There were some formatting issues with your comment (you need to quote or use code blocks with angle bracket tokens) so I edited it.
I was not suggesting that there could be one routine that does both initialize and finalize, only that the initialize and finalize routines are usually related and naturally fit into one module.
In the current PR, the item

<init>GFS_initialize_scm</init>

results in a call to the routine, GFS_initialize_scm_run while I am just suggesting that it generate a call to GFS_initialize_scm_init. In practice, we would probably see entries such as:

<init>GFS_scm</init>
. . .
<finalize>GFS_scm</finalize>

[climbfuji]

Apologies for the bad formatting! Yes that's totally fine with me, and that's also how I understood your comment.

I am just wondering whether we should give up that concept of having extra <init> and <finalize> sections at all and instead advise users to use a separate group like

<group name="init_final">
  <subcycle loop=1>
    <scheme>my_special_init_and_final_scheme</scheme>
  </subcycle>
</group>

(the format of this part got messed up in my previous comment)

because the my_special_init_and_final_scheme would be the same as in your suggestion (i.e. init and finalize routines are used, _run is empty). That way we could get rid of a lot of redundant code that does the extra handling of the <init> and <finalize> sections in the SDF.

[gold2718]

I think the issue of having <init> (or <initialize>) and <finalize> scheme tags is separate from the issue of group names. For the record, I think it may be useful for any group to be able to host <init> and <finalize> schemes.

I find the issue of group names to be more problematic. For a suite to be interoperable, each host model that uses it must be able to recognize and properly use each group name. This is not the best place for a discussion of group names but I am not sure what to do with names such as fast_physics, physics or radiation and I would not expect your model to know what to do with before_coupling and after_coupling (which are essentially the names of the current CESM-CAM groups).

[climbfuji]

Update 20180529: following @gold2718 's recommendation, the logic has been changed to run the _init subroutine of the additional/optional suite init scheme specified as <init>XXX</init>, similarly for <finalize>YYY</finalize>. This allows XXX and YYY to be the same scheme/module.

[climbfuji]

Parts of this PR (cnvc90) where replaced by #74. Once a separate PR for the HRRR Thompson scheme is created and merged, this PR will be closed.

[climbfuji]

The proposed changes in this PR have been superseded by separate PRs for updating the metadata tables for HRRR physics (Thompson MP and RUC LSM), the implementation of the first call to CCPP-compliant physics (cnvc90), and the addition of the HRRR Thompson MP scheme.