capgen always needs optional group name (6 hours)

[gold2718]

All host model interface routines (except suite and suite part lists) must take a group name as an optional argument.

• At run time if no group is specified, run all groups in SDF order.
• At other times, only call routines associated with the specified group.

[gold2718]

If a host model calls <host>_ccpp_physics_initialize with group 'A' but not group 'B', then we have to consider group 'B' uninitialized. This greatly complicated the state machine since a call to <host>_ccpp_physics_run for group 'A' should run but a call to <host>_ccpp_physics_run for group 'B' should return an error code and error message.

The same issues crop up in the <host>_ccpp_physics_finalize as well as <host>_ccpp_physics_timestep_initial and <host>_ccpp_physics_final.

Also, if the user calls <host>_ccpp_physics_run with no group name, should group 'A' run but not group 'B'? Should group 'A' run but the routine still returns an error from the attempt to run group 'B'?

What are the full semantics of this option? @climbfuji? @grantfirl?

[climbfuji]

I can tell you how this works at the moment. The framework is not really handling this logic, it is up the host model developers to arrange their ccpp_physics_init calls (and subsequent run and finalize calls) in a way that it makes sense. In the UFS, there is one separate ccpp_physics_init call to group fast_physics, and this needs to happen in the dycore before the "slow/traditional" physics can be initialized (because at that time, the GFS DDTs that are used for the slow physics aren't even allocated).

Once the dycore did its adiabatic init step (after ccpp_physics_init for the fast group, it runs the adiabatic init step, which means running the dycore forward and backward for two steps each), the GFS DDTs get allocated, the physics restart files read, and then ccpp_physics_init gets called w/o a group argument. Because group fast_physics has been initialized already, it is skipped automatically.

Subsequent timestep_init, run and finalize calls are all set up so that the order makes sense. I don't think we can/should expect the framework to handle all this logic, some thinking must be involved on the host model developer side.

[gold2718]

I don't think we can/should expect the framework to handle all this logic, some thinking must be involved on the host model developer side.

This philosophy works as long as the physics suite is designed along with the host model -- in other words, no portability at all for suites.

I am having trouble trying to figure out how to incorporate this (apparently fairly specific to the UFS model) 'design' with the needs of other models and physics suites. For instance, capgen will automatically create suite variables in certain cases, for instance, if group 'A' comes before group 'B' and creates a variable which is needed by group 'B'. This could really cause trouble if, as in the UFS, different groups in a "suite" are not even on the same decomposition and the groups can be initialized "out of order".

I am not seeing any way to modify capgen to be able to handle a single "suite" where the data is not on the same decomposition. If I make a run-time call to any of the current UFS suites with no group name, will that run correctly (i.e., run all groups in order)?

[climbfuji]

I don't think we can/should expect the framework to handle all this logic, some thinking must be involved on the host model developer side.

This philosophy works as long as the physics suite is designed along with the host model -- in other words, no portability at all for suites.

I am having trouble trying to figure out how to incorporate this (apparently fairly specific to the UFS model) 'design' with the needs of other models and physics suites. For instance, capgen will automatically create suite variables in certain cases, for instance, if group 'A' comes before group 'B' and creates a variable which is needed by group 'B'. This could really cause trouble if, as in the UFS, different groups in a "suite" are not even on the same decomposition and the groups can be initialized "out of order".

I am not seeing any way to modify capgen to be able to handle a single "suite" where the data is not on the same decomposition. If I make a run-time call to any of the current UFS suites with no group name, will that run correctly (i.e., run all groups in order)?

No, it won't, at least not when the fast physics are used. Without those it could work.

[gold2718]

I am not seeing any way to modify capgen to be able to handle a single "suite" where the data is not on the same decomposition. If I make a run-time call to any of the current UFS suites with no group name, will that run correctly (i.e., run all groups in order)?

No, it won't, at least not when the fast physics are used. Without those it could work.

Then there is no way to implement this in capgen in a way that would be compatible with NCAR host models.

[dustinswales]

This is not needed. In Capgen, a "suite_part_list" is created that contains a list of group name(s), or "suite_parts", in the suites ccpp _run phase. The "suite_part" is a mandatory input to the host caps, so the host can call the physics in any order they wish (i.e. call the suite part list in order)