b4b-dev: Python scripts: Require user to specify lon format when ambiguous#3024
Merged
samsrabin merged 32 commits intoESCOMP:b4b-devfrom Apr 16, 2025
Merged
Conversation
samsrabin
changed the title
7 tasks
Member
Author
|
* Require that user specify whether longitude is in [-180, 180] format (i.e., centered around Prime Meridian) or [0, 360] format (i.e., centered around International Date Line). * Specified as --lon-type, either 180 or 360 (respectively) * Resolves ESCOMP#2017 * Resolves ESCOMP#3001
samsrabin
force-pushed
the
fix-python-tools-longitude-format
branch
from
dd68889 to
6b29b53
Compare
samsrabin
added
bug
github-project-automation
Bot
moved this to Ready to start (or start again)
in CTSM: Upcoming tags
samsrabin
moved this from Ready to start (or start again)
to In progress - master/b4b-dev
in CTSM: Upcoming tags
samsrabin
commented
Apr 3, 2025
samsrabin
commented
Apr 3, 2025
Also improve an error message.
samsrabin
changed the title
samsrabin
added
PR status: awaiting review
samsrabin
changed the title
samsrabin
added
documentation
samsrabin
commented
Apr 5, 2025
ekluzek
approved these changes
Apr 10, 2025
Contributor
ekluzek
left a comment
ekluzek
left a comment
There was a problem hiding this comment.
Cool, this is great, and makes everything so much more robust.
I do have both a few things I'd like you to do, and some suggestions on things you can decide on. But, I'm marking as Approve, so you don't have to track me down again.
I feel the strongest about removing using of "International Date Line" for something like 180m for 180 Meridian. And I have a few possible suggestions to _detect_lon_type, where I think pulling in something there would be good. But, leaving it up to you to decide on this.
ekluzek
changed the title
samsrabin
removed
next
samsrabin
force-pushed
the
fix-python-tools-longitude-format
branch
from
42a03b4 to
c64bc2e
Compare
github-project-automation
Bot
moved this from In progress - master/b4b-dev
to Done (non release/external)
in CTSM: Upcoming tags
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
At the moment, our Python tools are dangerous in that they can allow the user to enter longitude in the [-180, 180] format when the tools actually assume the [0, 360] format. This PR fixes that by, in ambiguous cases, requiring the user to specify the format they're using with
--lon-typeeither 180 or 360.Specific notes
Contributors other than yourself, if any: None
CTSM Issues Fixed:
Are answers expected to change (and if so in what way)? No
Any User Interface Changes (namelist or namelist defaults changes)? No
Does this create a need to change or add documentation? Did you do so? Yes; see ESCOMP/ctsm-docs#9.
Testing performed, if any:
As of b97904f:
clm_pymodstest suite