Add support for scheme w/o run phase

[dustinswales]

Here we include a small fix to allow for schemes without run phases.

Capgen assumes that all schemes have a run phase, which is not true in practice. During the "scheme analyze" section, if a scheme doesn't contain a run phase we set a flag to true (no_run_phase). Then this flag is queried later in the "scheme write" section.

There are no interface changes.

Addresses #543

Testing has been expanded to contain a scheme w/o a run phase.

[gold2718]

Hmm, that is a lot less invasive than I expected, good work!

[climbfuji]

This just says phase, is phase always run?

[dustinswales]

This is to catch instances when "func" doesn't contain a run.
But yeah, phase can be init, run, or final, but we don't care if init and final are not present.

[climbfuji]

I still don't understand the logic. Somewhere, the code calls analyze for a certain phase (which can be anything you said: init, final, ...). Then in line 1144, you check if that phase is in the func dictionary. If it is not, you set has_run_phase to False. That makes sense if phase is run, but not if the argument phase is init?

[dustinswales]

The way I understand it is, this may be wrong:

Capgen creates group caps for each CCPP phase except for the run phase, and caps for each group's run phase. For example, in the SCM GFS_v16 SDF, we have the following caps created (4 ccpp phase caps, and 3 group caps):
public :: SCM_GFS_v16_initialize
public :: SCM_GFS_v16_timestep_initial
public :: SCM_GFS_v16_time_vary
public :: SCM_GFS_v16_radiation
public :: SCM_GFS_v16_physics
public :: SCM_GFS_v16_timestep_final
public :: SCM_GFS_v16_finalize

So when analyzing/writing the group caps you can only have phase=run.

[climbfuji]

Oh, that is fundamentally different from prebuild. In prebuild, there is a cap for each phase and each group. I think right now that limitation in capgen isn't a problem, but I would prefer that check in the code just in case the capgen implementation changes in the future and analyze at the group level can get called for other phases, too.

For example:

            if phase in func:
                my_header = func[phase]
            #else:
            elif phase == 'run':
                self._has_run_phase = False
                return set()

[climbfuji]

There's another option though. We could try to treat the FV3 dycore with the fast physics as its own "host model" for CCPP framework purposes. I thought about this in the past, when I heard discussions about moving more physics into the FV3 dycore ("inline physics"). I think that should be possible with relatively little engineering on the build system side.

[gold2718]

We have discussed one way to handle this but I can't find the reference right now. The idea would be that we have two ways to combine sub-suites. Do you recall where that took place or should I add what I recall to #275 ?

[climbfuji]

If you could, yes please. I don't remember. Thanks very much!

[gold2718]

I have added what I recall to the description section of #275 .

[climbfuji]

Thanks! Yes, I think this would give us the desired capability.

[climbfuji]

@dustinswales Let's wait until my pr to merge feature/capgen into main is merged. We should then target main instead of feature/capgen.

[climbfuji]

This was not tested with the UFS. We unfortunately can't merge code into the main branch without going through the proper regression testing procedure.