NCAR / NCAR/ccpp-framework

Rethinking horizontal dimensions

Open
#760 2 comments 0 reactions 1 assignee View on GitHub

@climbfuji is already working on this.

Since May 27, 2026.

enhancement
Dominant language
Python
Stars
25
Forks
67
Avg merge
3d 8h
Merged PRs (30d)
2

Description

Description

Currently, ccpp_prebuild and ccpp_capgen require using different horizontal dimensions (standard names) depending on the context: host model metadata always uses horizontal_dimension, scheme metadata uses horizontal_loop_extent or horizontal_loop_begin:horizontal_loop_end for the run phase, and horizontal_dimension for all other phases.

This reflects the inner workings of the CCPP physics calls: During the run phase, the physics may be called with horizontal subsets (chunks) of the entire data owned by an MPI task to support cache reuse and/or parallel processing using OpenMP. However, it is not clear why the user or the physics schemes need to know about these details. For a physics developer or a physics scheme, it doesn't matter what mechanism is used internally - all they care about is that an array is passed with a certain horizontal dimension.

Developers and users have complained about this unnecessary and confusing requirement to use one or the other standard name, depending on the context.

Solution

horizontal_dimension should be the only horizontal dimension variable (standard name) ever being used in the dimensions attribute in the metadata for host and scheme metadata, regardless of the phase. The CCPP framework can handle the necessary logic to pass the correct data to the physics scheme for the given context, as long as the host model provides the necessary information in three variables: horizontal_dimension, horizontal_loop_begin, horizontal_loop_end. The latter two need to be set independently for each OpenMP task if the physics run phase is called by multiple OpenMP threads in parallel. Without OpenMP threading and without chunking of data for the physics run phase, the host model simply sets horizontal_loop_begin=1 and horizontal_loop_end=horizontal_dimension.

Note that there is no need to maintain horizontal_loop_extent internally, since this case is covered by horizontal_loop_begin and horizontal_loop_end.

Alternatives (optional)

Do nothing and keep confusing people.

Related to (optional)

We discussed this issue in a CCPP framework meeting several weeks ago, and we agreed that we can just use horizontal_dimension on the user-facing side.

This will be implemented in the next-generation code generator.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.