-
Notifications
You must be signed in to change notification settings - Fork 27
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
[uwtools_integration] Integrate ics/lbcs #266
base: uwtools_integration
Are you sure you want to change the base?
Conversation
51c05a0
to
3b65a6c
Compare
… into integrate_ics_lbcs
This will need to be updated with the changes from #268, but it is sufficiently complete otherwise for feedback |
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.
Here's my initial review. Will review more of it soon!
Co-authored-by: NaureenBharwaniNOAA <[email protected]>
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.
I think there might be some changes coming, and will re-review after those. Maybe some changes suggested in this batch of comments will appear, too.
scripts/chgres_cube.py
Outdated
return parser.parse_args(argv) | ||
|
||
|
||
# pylint: disable=too-many-locals, too-many-statements, too-many-branches |
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.
# pylint: disable=too-many-locals, too-many-statements, too-many-branches | |
# pylint: disable-next=too-many-locals, too-many-statements, too-many-branches |
I'm not sure this will work -- whether disable-next
will apply to the next block and not just the next line, for those suppressors that relate to this function. If not, this line should probably move to the top of the module (after the #!
) because, without -next
, it applies to every line of code until the end of the module, and I think we should make this kind of interference with the linter more visibly obvious.
But some of this is also not bad advice from the linter: This function in 177 lines long. Could it be refactored into smaller, purpose-specific functions for better readability? I see what look like section comments describing various (maybe) unrelated operations, each of which could be its own function, which would then be somewhat self-documenting, e.g. we could change
# Extract driver config from experiment config
to function call
driver = get_driver(expt_config_cp)
and factor out the code to that function. If nothing else, there is a giant if
/ else
block where the two alternatives might better be encapsulated in two functions.
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.
I'm leaving this open for now to see what you think of the current shorter version. It might be a cleaner version as well if I moved the file linking or the loop off to a helper function?
70bdfb4
to
25fd2b4
Compare
Hi all, let's hold off on reviews for the moment. I'm going to push some changes. We'll let you know when it's ready for the next round of review. |
DESCRIPTION OF CHANGES:
A full integration of uwtools for the make_ics and make_lbcs tasks.
All fundamental tests have passed
Type of change
TESTS CONDUCTED: