Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of CCPP timestep_init and timestep_final phases #344

Merged
merged 4 commits into from
Jan 8, 2021

Conversation

climbfuji
Copy link
Collaborator

@climbfuji climbfuji commented Dec 17, 2020

This PR contains the following changes:

  • Implementation of CCPP timestep_init and timestep_final phases
  • Use CCPP_stages dictionary to abbreviate timestep_init and timestep_final as tsinit and tsfinal in cap subroutine names
  • Drop requirement that CCPP schemes have to have subroutines for each phase, even if those are empty and don't have CCPP metadata tables

Associated PRs:

ufs-community/ufs-weather-model#337
NOAA-EMC/fv3atm#217
NCAR/ccpp-physics#534
#344
NOAA-EMC/GFDL_atmos_cubed_sphere#47

For regression testing information, see ufs-community/ufs-weather-model#337.

- use CCPP_stages dictionary to abbreviate timestep_init and timestep_final as tsinit and tsfinal in cap subroutine names
- drop requirement that CCPP schemes have to have (stub) subroutines for each phase
@climbfuji
Copy link
Collaborator Author

I am opening this PR for review. Although unlikely, I may have to pull in updates from NCAR master in case anything gets committed until it is the turn for this PR. But the code changes itself should be final.

Copy link
Collaborator

@gold2718 gold2718 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not see anything concerning but I have a couple of questions.

Comment on lines +138 to +147
# Add special kind variables
if tmpvar.type in STANDARD_VARIABLE_TYPES and tmpvar.kind and not tmpvar.type == STANDARD_CHARACTER_TYPE:
kind_var_standard_name = tmpvar.kind
if not kind_var_standard_name in local_kind_and_type_vars:
if not kind_var_standard_name in metadata_define.keys():
raise Exception("Kind {kind} not defined by host model".format(kind=kind_var_standard_name))
kind_var = metadata_define[kind_var_standard_name][0]
module_use.append(kind_var.print_module_use())
local_kind_and_type_vars.append(kind_var_standard_name)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this directly related to the new phases? I do not immediately see the connection.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indirectly. By coincidence, all existing phases (_run, _init, _finalize) always had at least one scheme for each group that used variables with a kind_phys or kind_dyn type directly (not just as part of a DDT_. Because of the lines immediately preceding the new block in lined 138-147, kind_phys was getting passed correctly to the auto-generated caps.

For the time_vary group and phase timestep_init, only the DDTs needed to be passed from the host model to the auto-generated cap, and kind_phys was thus not known to the cap. When blocked data conversions happen, the temporary variables for the DDT constituents are of kind_phys. Thus the additional logic.

@@ -265,7 +277,7 @@ def write(self):
# which comes in as a scalar for any potential block/thread via the argument list.
ccpp_var = None
parent_standard_names = []
for ccpp_stage in CCPP_STAGES:
for ccpp_stage in CCPP_STAGES.keys():
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the .keys() here redundant? Same question on line 303 below.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, haven't tried. I generally prefer to add .keys(), because it makes it explicit what we are looping over.

Comment on lines +509 to +510
self._parents = { ccpp_stage : {} for ccpp_stage in CCPP_STAGES.keys() }
self._arguments = { ccpp_stage : [] for ccpp_stage in CCPP_STAGES.keys() }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think you need .keys() here (or below).

@climbfuji climbfuji requested a review from gold2718 January 7, 2021 16:27
Copy link
Contributor

@llpcarson llpcarson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved

Copy link
Collaborator

@gold2718 gold2718 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing the same code I reviewed before. Does that sound right?

@climbfuji
Copy link
Collaborator Author

I'm seeing the same code I reviewed before. Does that sound right?

Yes, because I replied to your comment that I prefer to explicitly spell out .keys(), and I gave an explanation why the additional logic is required that is not strictly related to timestep_init and timestep_final. I don't know any better way to ask for looking at my answers then requesting a review again. Thanks!

@gold2718
Copy link
Collaborator

gold2718 commented Jan 8, 2021

I don't know any better way to ask for looking at my answers then requesting a review again.

I don't either. I was just a bit worried because I saw a new commit ab48311 but no changes for me to review and I wanted to make sure I was looking at it right.

@climbfuji
Copy link
Collaborator Author

I don't know any better way to ask for looking at my answers then requesting a review again.

I don't either. I was just a bit worried because I saw a new commit ab48311 but no changes for me to review and I wanted to make sure I was looking at it right.

Thanks for checking, got it.

@climbfuji climbfuji merged commit 612dd1a into NCAR:master Jan 8, 2021
@climbfuji climbfuji deleted the timestep_init_final branch June 27, 2022 03:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants