-
Notifications
You must be signed in to change notification settings - Fork 0
Compare two model development runs in a single run of CMEW #259
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
base: main
Are you sure you want to change the base?
Conversation
…el2.conf and remove its MODELS_OPTION from other files. Move configure_for rose-app.conf to a bash script.
…erence variant labels.
app/configure_for/update_recipe_file.py as they are no longer needed. Revert to using environment variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partial review...
first_dataset.update( | ||
{ | ||
"start_year": start_year, | ||
"ensemble": variant_label_reference, | ||
"end_year": end_year, | ||
} | ||
) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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?
g_variant_label = "r1i1p1f1" # = ensemble test | ||
g_variant_label_reference = "r1i1p1f3" # = ensemble reference |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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): |
There was a problem hiding this comment.
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()
?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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): |
There was a problem hiding this comment.
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): |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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....
g_variant_label = "r1i1p1f1" # = ensemble test | ||
g_variant_label_reference = "r1i1p1f3" # = ensemble reference |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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
# 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() |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Closes #142.
PR creation checklist for the developer
<issue_number>
above ☝️ been replaced with the issue number?main
been selected as the base branch?<issue_number>_<short_description_of_feature>
?good first issue
label) been added to the PR?Climate Model Evaluation Workflow (CMEW)
project been added to the PR?Definition of Done for the developer
doc
directory) related to the change been updated appropriately, including the Quick Start section?PR creation checklist for the reviewer
<issue_number>
above ☝️ been replaced with the issue number?main
been selected as the base branch?<issue_number>_<short_description_of_feature>
?good first issue
label) been added to the PR?Climate Model Evaluation Workflow (CMEW)
project been added to the PR?Definition of Done for the reviewer
doc
directory) related to the change been updated appropriately, including the Quick Start section?