Skip to content

Conversation

mo-johnmo
Copy link
Contributor

@mo-johnmo mo-johnmo commented Mar 25, 2025

Closes #142.

PR creation checklist for the developer

  • Has <issue_number> above ☝️ been replaced with the issue number?
  • Has main been selected as the base branch?
  • Does the feature branch name follow the format <issue_number>_<short_description_of_feature>?
  • Does the text of the PR title exactly match with the text (not including the issue number) of the issue title?
  • Have appropriate reviewers been added to the PR (once it is ready for review)?
  • Has the PR been assigned to the developer(s)?
  • Have the same labels as on the issue (except for the good first issue label) been added to the PR?
  • Has the Climate Model Evaluation Workflow (CMEW) project been added to the PR?
  • Has the appropriate milestone been added to the PR?

Definition of Done for the developer

  • Does the change in this PR address the above issue / have all acceptance criteria been met?
  • Does the change in this PR follow the requirements in the wiki: Developer Guide (including copyrights)?
  • Have new tests related to the change been added?
  • Do all the GitHub workflow checks pass?
  • Do all the tests run locally and pass? (Note: the tests are not run by the GitHub workflow, see wiki: Run the tests locally)
  • Has the API documentation (e.g. docstrings in Python modules) related to the change been updated appropriately?
  • Has the user documentation (i.e. everything in the doc directory) related to the change been updated appropriately, including the Quick Start section?
  • Do the HTML pages render correctly? (See wiki: Build the documentation locally)

PR creation checklist for the reviewer

  • Has <issue_number> above ☝️ been replaced with the issue number?
  • Has main been selected as the base branch?
  • Does the feature branch name follow the format <issue_number>_<short_description_of_feature>?
  • Does the text of the PR title exactly match with the text (not including the issue number) of the issue title?
  • Have appropriate reviewers been added to the PR (once it is ready for review)?
  • Has the PR been assigned to the developer(s)?
  • Have the same labels as on the issue (except for the good first issue label) been added to the PR?
  • Has the Climate Model Evaluation Workflow (CMEW) project been added to the PR?
  • Has the appropriate milestone been added to the PR?

Definition of Done for the reviewer

  • Does the change in this PR address the above issue / have all acceptance criteria been met?
  • Does the change in this PR follow the requirements in the wiki: Developer Guide (including copyrights)?
  • Have new tests related to the change been added?
  • Do all the GitHub workflow checks pass?
  • Do all the tests run locally and pass? (Note: the tests are not run by the GitHub workflow, see wiki: Run the tests locally)
  • Has the API documentation (e.g. docstrings in Python modules) related to the change been updated appropriately?
  • Has the user documentation (i.e. everything in the doc directory) related to the change been updated appropriately, including the Quick Start section?
  • Do the HTML pages render correctly? (See wiki: Build the documentation locally)

@mo-johnmo mo-johnmo self-assigned this Mar 26, 2025
@mo-johnmo mo-johnmo added the enhancement New feature or request label Mar 26, 2025
@mo-johnmo mo-johnmo added this to the v0.1.0 milestone Mar 26, 2025
…el2.conf

and remove its MODELS_OPTION from other files.  Move configure_for rose-app.conf
to a bash script.
@mo-johnmo mo-johnmo marked this pull request as ready for review March 27, 2025 10:28
@alistairsellar alistairsellar modified the milestones: v0.1.0, v0.2.0 Mar 27, 2025
app/configure_for/update_recipe_file.py as they are no longer needed.  Revert
to using environment variables.
Copy link
Collaborator

@alistairsellar alistairsellar left a comment

Choose a reason for hiding this comment

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

Partial review...

Comment on lines 68 to 74
first_dataset.update(
{
"start_year": start_year,
"ensemble": variant_label_reference,
"end_year": end_year,
}
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

first_dataset will need to have the same keys updated as second_dataset (below). so project, exp & activity need added. exp should be hard-coded to "historical" for first_dataset.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These changes and others as discussed in Teams, have been made in commit b04203b.

Copy link
Collaborator

@alistairsellar alistairsellar left a comment

Choose a reason for hiding this comment

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

Hi @mo-johnmo. It's looking good. I've got a couple of questions. Can we discuss online after 2:15?

Comment on lines 9 to 10
g_variant_label = "r1i1p1f1" # = ensemble test
g_variant_label_reference = "r1i1p1f3" # = ensemble reference
Copy link
Collaborator

Choose a reason for hiding this comment

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

What does the g_ prefix indicate in these variable names?

Copy link
Collaborator

Choose a reason for hiding this comment

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

...which means these global variables are not needed.



def main():
def update(recipe_path, variant_label, variant_label_reference):
Copy link
Collaborator

Choose a reason for hiding this comment

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

The additional layer of function seems unnecessary. Is there a reason not to handle the two new vars in the same way as recipe_path was treated before in main()?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for the explanation on our call. Since we don't call this intermediate function at the moment, please to the previous structure, with update_recipe called directly by main

def mock_env_vars(monkeypatch):
monkeypatch.setenv("START_YEAR", "1993")
monkeypatch.setenv("NUMBER_OF_YEARS", "1")
monkeypatch.setenv("VARIANT_LABEL", g_variant_label)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why set these with variables instead of hard-coding like the YEAR variables?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Now we've decided to feed these to update_recipe as environment variables, these can be specified in the same way as START_YEAR etc....

json.dump(request, file, separators=(",\n", ": "))


def make_request_file(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Similar to above, is there a strong reason to introduce an extra level to the function hierarchy?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Since we only want to test create_request, we don't need this additional layer. Please revert to calling create_request and write_request directly from main

… while

retaining the variant_label and variant_label_reference additions.
Copy link
Collaborator

@alistairsellar alistairsellar left a comment

Choose a reason for hiding this comment

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

Hi @mo-johnmo. Here are the changes we discussed.

Plus confirmation on the question I said I'd get a second opinion on, and a couple of new requests about the argparse stuff.



def update_recipe(recipe_path):
def update_recipe(recipe_path, variant_label, variant_label_reference):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for discussion just now. We decided to feed these variables to update_recipe as environment variables, for consistency with START_YEAR etc.



def main():
def update(recipe_path, variant_label, variant_label_reference):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for the explanation on our call. Since we don't call this intermediate function at the moment, please to the previous structure, with update_recipe called directly by main

def mock_env_vars(monkeypatch):
monkeypatch.setenv("START_YEAR", "1993")
monkeypatch.setenv("NUMBER_OF_YEARS", "1")
monkeypatch.setenv("VARIANT_LABEL", g_variant_label)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Now we've decided to feed these to update_recipe as environment variables, these can be specified in the same way as START_YEAR etc....

Comment on lines 9 to 10
g_variant_label = "r1i1p1f1" # = ensemble test
g_variant_label_reference = "r1i1p1f3" # = ensemble reference
Copy link
Collaborator

Choose a reason for hiding this comment

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

...which means these global variables are not needed.

# noqa : 36 : Ignore warning about monkey_env not being used; it is used
# silently but not referenced.

request = make_request_file(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please just test the create_request function by comparing dicts as before. Second reviewer @ehogan agrees that we don't want to extend the scope of the test in this PR.

A bit more detail in case of interest... we have end-to-end tests to cover the interactions between functions including files. The unit test is to test the smallest sensible unit, and tests the logical content is correct.

json.dump(request, file, separators=(",\n", ": "))


def make_request_file(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since we only want to test create_request, we don't need this additional layer. Please revert to calling create_request and write_request directly from main

Comment on lines 105 to 118
# Get args from cmd line. This needs to be told which of test or reference
# settings to use, it cannot decide itself.
# Mandatory flags or missing arguments for a flag are handled by the parser
# Optional flags must be handled explicitly unless given a default value.
parser = argparse.ArgumentParser(
prog="create-request-file",
description="Create a request file to pass to CDDS-convert",
)
request = create_request()
write_request(request, target_path)
parser.add_argument("-p", help="Request-file path", required=True)
parser.add_argument("-m", help="Model_id", required=True)
parser.add_argument("-s", help="Suite_id", required=True)
parser.add_argument("-c", help="Calendar", required=True)
parser.add_argument("-v", help="Variant Label", required=True)
args = parser.parse_args()
Copy link
Collaborator

Choose a reason for hiding this comment

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

A good convention to follow with argparse to keep main tidy is to put all the argparse commands in a single function called parse_arguments and call this from main with

args = parse_arguments()`

Please follow this approach here.

request = create_request()
write_request(request, target_path)
parser.add_argument("-p", help="Request-file path", required=True)
parser.add_argument("-m", help="Model_id", required=True)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
parser.add_argument("-m", help="Model_id", required=True)
parser.add_argument("--model-id", "-m", help="Model_id", required=True)

Please include long flag names for all these arguments.

@alistairsellar alistairsellar self-assigned this Apr 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compare two model development runs in a single run of CMEW
2 participants