Schemes that appear multiple times in an SDF

[peverwhee]

Hi CCPPers - philosophical question:

When the same scheme appears multiple times in a suite definition file, what is the desired behavior in the suite cap?

SDF example:

<suite name="test_suite" version="1.0">
  <group name="group_a">
    <scheme>scheme1</scheme>
    <scheme>repeated_scheme</scheme>
    <scheme>scheme2</scheme>
    <scheme>repeated_scheme</scheme>
  </group>
  <group name="group_b">
    <scheme>scheme3</scheme>
    <scheme>repeated_scheme</scheme>
    <scheme>scheme4</scheme>
    <scheme>repeated_scheme</scheme>
  </group>
</suite>

1. All phases are called as many times as the SDF appears. e.g.

subroutine test_suite_initialize()
  call scheme1_init()
  call repeated_scheme_init()
  call scheme2_init()
  call repeated_scheme_init()
  call scheme3_init()
  call repeated_scheme_init()
  call scheme4_init()
  call repeated_scheme_init()
end test_suite_initialize

subroutine test_suite_timestep_init()
  call scheme1_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme2_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme3_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme4_timestep_init()
end test_suite_timestep_init

subroutine test_suite_groupa()
  call scheme1_run()
  call repeated_scheme_run()
  call scheme2_run()
  call repeated_scheme_run()
end subroutine test_suite_groupa

subroutine test_suite_groupb()
  call scheme3_run()
  call repeated_scheme_run()
  call scheme4_run()
  call repeated_scheme_run()
end subroutine test_suite_groupb

subroutine test_suite_timestep_final()
  call scheme1_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme2_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme3_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme4_timestep_final()
end test_suite_timestep_final

subroutine test_suite_finalize()
  call scheme1_final()
  call repeated_scheme_final()
  call scheme2_final()
  call repeated_scheme_final()
  call scheme3_final()
  call repeated_scheme_final()
  call scheme4_final()
  call repeated_scheme_final()
end test_suite_finalize

2. Only timestep_init, run, and timestep_final are called multiple times. Init and final are only called once total e.g.

subroutine test_suite_initialize()
  call scheme1_init()
  call repeated_scheme_init()
  call scheme2_init()
  call scheme3_init()
  call scheme4_init()
end test_suite_initialize

subroutine test_suite_timestep_init()
  call scheme1_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme2_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme3_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme4_timestep_init()
end test_suite_timestep_init

subroutine test_suite_groupa()
  call scheme1_run()
  call repeated_scheme_run()
  call scheme2_run()
  call repeated_scheme_run()
end subroutine test_suite_groupa

subroutine test_suite_groupb()
  call scheme3_run()
  call repeated_scheme_run()
  call scheme4_run()
  call repeated_scheme_run()
end subroutine test_suite_groupb

subroutine test_suite_timestep_final()
  call scheme1_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme2_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme3_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme4_timestep_final()
end test_suite_timestep_final

subroutine test_suite_finalize()
  call scheme1_final()
  call repeated_scheme_final()
  call scheme2_final()
  call scheme3_final()
  call scheme4_final()
end test_suite_finalize

3. Only run is called multiple times.

subroutine test_suite_initialize()
  call scheme1_init()
  call repeated_scheme_init()
  call scheme2_init()
  call scheme3_init()
  call scheme4_init()
end test_suite_initialize

subroutine test_suite_timestep_init()
  call scheme1_timestep_init()
  call repeated_scheme_timestep_init()
  call scheme2_timestep_init()
  call scheme3_timestep_init()
  call scheme4_timestep_init()
end test_suite_timestep_init

subroutine test_suite_groupa()
  call scheme1_run()
  call repeated_scheme_run()
  call scheme2_run()
  call repeated_scheme_run()
end subroutine test_suite_groupa

subroutine test_suite_groupb()
  call scheme3_run()
  call repeated_scheme_run()
  call scheme4_run()
  call repeated_scheme_run()
end subroutine test_suite_groupb

subroutine test_suite_timestep_final()
  call scheme1_timestep_final()
  call repeated_scheme_timestep_final()
  call scheme2_timestep_final()
  call scheme3_timestep_final()
  call scheme4_timestep_final()
end test_suite_timestep_final

subroutine test_suite_finalize()
  call scheme1_final()
  call repeated_scheme_final()
  call scheme2_final()
  call scheme3_final()
  call scheme4_final()
end test_suite_finalize

Poll below. Thanks!

[climbfuji]

Reasoning for my vote:

1. Per CCPP requirements, the init and finalize phases must be idempotent, means they can be called as many times as needed and the result will be the same.
2. You need to be able to call each group individually, and in whatever order you want. That requires that each group must be calling the init phase.

[peverwhee]

Thanks @climbfuji !

In regards to your second point, don't we only differentiate groups at the run phase? At least in capgen, I don't believe there is a way to call, for example, the init phases of only one group.

[climbfuji]

In prebuild, there definitely is, and it is also required for the UFS to function.

The fast physics group (that runs physics in the dycore) must be initialized earlier and separately from the rest. The variables and necessary namelist for the rest haven't been read at this time, and the dycore also cannot access the slow physics variables (and vice versa).

[peverwhee]

That makes sense (and sounds like it'll require some capgen modifications!). With that in mind, would you say that only calling the init phase once per group would make sense? Or does it not matter because of the idempotent part?

[climbfuji]

We need to think about this very carefully. There is the additional dimension instances for cases where multiple instances (ensemble members) are running inside one model executable ("in core") that prebuild/ncar-ccpp-physics supports. At the very least, each init scheme must run once per group once per instance.

[gold2718]

@climbfuji points out that the CCPP Technical Documentation requires the init and finalize phases to be idempotent. That is, if they are called more than once, answers will not be affected. We feel this implies that the scheme code for these phases should also be idempotent. Since the timestep_init and timestep_finalize work similarly to init and finalize, they should also be idempotent.

[peverwhee]

Since @dustinswales 's #629 (changing from set to list), capgen now has the desired behavior (all phases called multiple times.

[mkavulich]

@peverwhee Can this discussion be closed as resolved?