Fix conservation of split divergence

[dennisYatunin]

This PR updates the SplitDivergence operator to make it discretely conservative for discontinuous fields. The current version is already conservative for fields that have been DSSed, but it includes additional terms at element boundaries that violate conservation for discontinuous quantities (e.g., velocities reconstructions on a cubed sphere).

The first commit in this PR removes the erroneous terms at element boundaries and updates the unit tests to demonstrate improved conservation properties. The unit tests are also simplified to avoid unnecessary checks and repetitive code.

The second commit in this PR makes the implementation of SplitDivergence more similar to the other spectral operators, ensuring correct use of RecursiveApply and consistent caching/indexing. Although this makes the code somewhat harder to read, it should simplify the process of removing RecursiveApply in #2417, with identical changes required for SplitDivergence and other spectral operators. (The convoluted cache indexing will also be removed from all operators in a future PR.) In addition, the docstring for SplitDivergence is updated to improve formatting and correct errors.

TODO: Update SplitDivergence in CUDA extension.

• Code follows the style guidelines OR N/A.
• Unit tests are included OR N/A.
• Code is exercised in an integration test OR N/A.
• Documentation has been added/updated OR N/A.

[tapios]

Just curious: I find these 6 lines harder to read than the pattern it replaces. What's the advantage of writing it this way?

[dennisYatunin]

The reason I did this was to enforce consistency with the rest of the code in this file, so future PRs that refactor RecursiveApply and DataLayouts will not be behavior changing. But I totally agree that this is harder to read and needs to be refactored soon.

The RecursiveApply functions in this file allow iteration over multiple mass fluxes and/or multiple scalar quantities within the same fused operation. I'm working on removing the RecursiveApply module entirely from ClimaCore while maintining this behavior in #2417, which should eliminate most of the complexity introduced here.

As for the convoluted indexing required by DataLayouts, I'm honestly not sure why that is used throughout this file. The original intent of DataLayouts was to rearrange values in global memory so that L1/L2 caching could be improved, but it's not clear to me how this is useful for MArrays that are already cached in register memory. I will explore this more carefully in a future PR that refactors the DataLayouts module. If I don't end up finding any benefit to wrapping register caches in IF and IJF DataLayouts, I will remove these wrappers from psi, out, and all other register caches in ClimaCore.

[tapios]

@dennisYatunin Is there anything in the way of merging this? (Aside from making sure it passes unit tests.)

[dennisYatunin]

No, I just needed to update the CUDA extension code. Hopefully the unit tests pass now.