-
Notifications
You must be signed in to change notification settings - Fork 3
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
Refactor fv3 runtime modules and image construction #185
Conversation
Builds a docker image with fv3net, vcm, and fv3gfs-python installed.
Currently getting this error:
|
@spencerkclark ^^^^ seems up your alley. Thoughts? |
Yup was just going to suggest pinning pandas; looks like you figured it out. This should be straightened out in the next release of xarray. |
haha. I saw the only difference between the images was pandas 1.0.2 vs 1.01. Why a "patch" update would break a release I have no idea. |
I think I've been in dependency hell a lot lately. |
Yeah they made some changes that broke indexing with the "nearest" method with a CFTimeIndex: pydata/xarray#3751. It's somewhat understandable since they don't have any tests for how we're subclassing Pandas may well address this on their end too...we'll see. Kind of a pain though that they went forward with their release anyway (we brought this to their attention ahead of time). |
Yah. I think this is unavoidable when using open source tools, honestly I put the blame on |
It's just annoying that I've burned by upstream dependencies of our dependencies twice in two days. |
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.
Nice and clean rework. Thanks, @nbren12. One requested change for the fv3net
Makefile, but otherwise LGTM.
pip wheel --no-deps external/vcm | ||
|
||
# pattern rule for building docker images | ||
build_image_%: |
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.
Neat. 🤩
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.
Looks good. I have one comment/suggestion about a function name. More generally, if we're moving to have some general purpose functions that can be used in runfiles, seems like we might want to formalize the "runfile config" idea. Possibly we could enforce that any configuration options that are read in by runfiles are under a runfile
item in fv3config.yml
.
@@ -10,7 +10,7 @@ class dotdict(dict): | |||
__delattr__ = dict.__delitem__ | |||
|
|||
|
|||
def get_config(): | |||
def get_runfile_config(): |
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 do you mean by a runfile config? Should we formalize this somehow? I see the value of the concept, but given what this function does it seems like get_sklearn_config
or something would be a better name.
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 agree with you, and have removed this function in #193. I think i will merge this as is though, just to get the ball rolling.
As part of the effort to adjust the runfile for the one_step jobs, I realized that I could share the following functionality:
online_modules
directory used there.After talking to @frodre and @oliverwm1, I decided to pull these routines into the top-level fv3net workspace. This involved the following changes:
prognostic_run
andfv3net
images to the/docker
folder./docker
which seem obsolete (last touched Oct 2019).make push_images
andmake build_images
workflows/prognostic_c48_run/online_modules
intofv3net/runtime
. This module will now be available to other workflows.Todo: