Handle dimensions for promoted variables

[peverwhee]

Description

Handle edge case where variable dimensions weren't getting added to the init phase calling list for allocation of promoted, suite-level variables.

Also includes logic to use horizontal_dimension in allocate statement for run-time only variables (with dimension horizontal_loop_extent)

Changes

• scripts/ccpp_suite.py: Add dimensions of promoted variable to init group calling list; use horizontal_dimension instead of horizontal_loop_extent if necessary
• scripts/suite_objects.py: Use horizontal_dimension instead of horizonal_loop_extent for allocation of promoted, suite-level variables
• test/capgen_test/*: add run-time only variables that need to be promoted and allocated (in run phase of two separate groups and used nowhere else)

User interface changes?: No

Fixes

closes #559

Testing

Test added for runtime-only promoted variables

[gold2718]

Couple of questions about code

[gold2718]

What is a case for this? Is it tested (capgen test seems to run fine without it)?

[peverwhee]

The case would be a promoted variable with no horizontal dimension, but the existing dimension(s) do still need to be added to the calling list for the init routine.

That said, thanks to your other suggestion, I reworked the code so this "else" is no more. I also altered the capgen_test to ensure promotion/allocation works as expected for a variable with no horizontal dimension

[gold2718]

Is the only other possibility? No other dimensions allowed?

[peverwhee]

A very good question.

Updated the logic in ccpp_suite to replace the horizontal dimension where it is and not remove other dimensions! This logic is now gone though, as I discovered it was unnecessary (the logic in ccpp_suite to promote variables handles the dimensions)

[dustinswales]

@peverwhee Maybe (probably) I don't understand the promotion business in Capgen, but looking at the test code I'm confused on the spirit of these changes.
There are two physics groups, both have schemes that use the promote_this_variable_to_suite variable, but in the physics1 group it is two-dimensional, whereas in the physics2 group it is one-dimensional. Why we would be doing something like this? How in the CCPP world is this allowable? (The host metadata is either 1D or 2D, so how do we parse this situation w/o error?)

[gold2718]

@dustinswales

@peverwhee Maybe (probably) I don't understand the promotion business in Capgen, but looking at the test code I'm confused on the spirit of these changes. There are two physics groups, both have schemes that use the promote_this_variable_to_suite variable, but in the physics1 group it is two-dimensional, whereas in the physics2 group it is one-dimensional. Why we would be doing something like this? How in the CCPP world is this allowable? (The host metadata is either 1D or 2D, so how do we parse this situation w/o error?)

To understand why this works, you have to know / learn about another corner of capgen. From the point of view of physics2, the variable, promote_this_variable_to_suite exists and has the required dimension so no worries :)
Note that temp_adjust is basically a 2-D (one level) scheme. When a scheme like this is called where the available data is 3-D, capgen automatically inserts a loop over the vertical dimension so that the 2-D scheme is called for each level. That is why this works (with or without promotion). However, if you tried to reverse physics1 and physics2, capgen should complain because the data needed by physics1 (variables with vertical_layer_dimension) is not present in the interface variables with the necessary dimensions. This should be tested if it is not already.

I hope this helps and does not just make everything more confusing.

[dustinswales]

@dustinswales

@peverwhee Maybe (probably) I don't understand the promotion business in Capgen, but looking at the test code I'm confused on the spirit of these changes. There are two physics groups, both have schemes that use the promote_this_variable_to_suite variable, but in the physics1 group it is two-dimensional, whereas in the physics2 group it is one-dimensional. Why we would be doing something like this? How in the CCPP world is this allowable? (The host metadata is either 1D or 2D, so how do we parse this situation w/o error?)

To understand why this works, you have to know / learn about another corner of capgen. From the point of view of physics2, the variable, promote_this_variable_to_suite exists and has the required dimension so no worries :) Note that temp_adjust is basically a 2-D (one level) scheme. When a scheme like this is called where the available data is 3-D, capgen automatically inserts a loop over the vertical dimension so that the 2-D scheme is called for each level. That is why this works (with or without promotion). However, if you tried to reverse physics1 and physics2, capgen should complain because the data needed by physics1 (variables with vertical_layer_dimension) is not present in the interface variables with the necessary dimensions. This should be tested if it is not already.

I hope this helps and does not just make everything more confusing.

@gold2718 Thanks for the explanation. Makes sense.
@peverwhee Personally, it helps me to see the autogenerated code, so I think it's a good idea to insert some autogenerated code snippets with the PR (next PR, no need this time)

[gold2718]

Looks good now, thanks!

[climbfuji]

Looks good to me, and I think I actually understand what it is doing ;-)

[peverwhee]

Merged into #549