Remove stub TimeSplit and ProcessSplit objects

[mkavulich]

Logic supporting time-split and process-split grouping natively in Capgen exists as only a stub capability. With no immediate plans to implement this feature, we should remove the unused code to simplify Capgen. If needed in the future this code can be recovered from history.

User interface changes?: No

Fixes: None

Testing:
test removed:
unit tests:
system tests:
manual testing:

[gold2718]

I'm really not sure what this is helping. These features were originally requested by the NCAR group to make it easier to implement different types of physics packages and regions within them.
Is this code hindering development somehow?

[gold2718]

Has the CAM-SIMA team signed off on this? CAM physics is time split but WRF physics is process split. Does the group planning on implementing WRF physics have no plans to leverage the process split class?

[nusbaume]

We have, and at least @peverwhee and I are generally ok with this. Although we will certainly need to support process and time-split physics groups, it is becoming unclear if having the framework manage it is the best option, or if alternative methods (like just implementing specialized tendency_updater schemes which can be runtime controlled) is better.

We of course can always add it back in later if is decided to be handled by the framework, but for now this seems like a reasonable decision to us.

[climbfuji]

I am all in favor of removing this. In UFS/NEPTUNE CCPP physics, the equivalent functionality was implemented in the physics themselves by requiring schemes to always return tendencies and never update the state in place. Interstitials handle the rest when needed.

Also, these are just stubs that are indeed in the way of debugging and getting capgen into the UFS and NEPTUNE. We can get actual code back in when we need it.

[gold2718]

Also, these are just stubs that are indeed in the way of debugging and getting capgen into the UFS and NEPTUNE. We can get actual code back in when we need it.

Can you please elaborate on exactly how this has hindered your work?
I am interested because I still would like to tackle the project which would remove the need for all those interstitial routines (which is a lot more code to test, debug, and maintain).

[climbfuji]

I believe this has never been implemented, therefore we can remove it from schema version 2 instead of creating a new schema version 3.

[dustinswales]

I support removing this. It's not currently implemented and further complicates the codebase.
The TimeSplit class is partially complete, and not implemented, while the Process Split class is empty. So it doesn't make much sense to keep these stubs in place IMO.
If/when we get to implementing this, we could just add it back in.

[peverwhee]

as @nusbaume mentioned, this is fine by me. If we decide we want this functionality in the future, we can add it back in. But at this point I'm in favor of trimming down framework features that can be achievable with interstitials.

[nusbaume]

Thanks @mkavulich!

[climbfuji]

@gold2718 A majority of us would like to move ahead with this - I am going to merge it.

After this PR is merged, I would like to ask the CCPP framework representatives of at least the host models using ccpp-prebuild to update the ccpp-framework code to the head of develop and, if successful, tag it as

<lower-case-host-model-identifier>_YYYY-MM-DD_ccpp-prebuild_final

to match the existing tags (e.g. sima_2026-04-13). SIMA folks, you are of course more than welcome to do the same.

After we have the tags, I will start removing ccpp-prebuild. An era comes to an end!