Skip to content
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

Merged
merged 14 commits into from
Mar 21, 2020

Conversation

nbren12
Copy link
Contributor

@nbren12 nbren12 commented Mar 17, 2020

As part of the effort to adjust the runfile for the one_step jobs, I realized that I could share the following functionality:

  1. the docker image built by the prognostic run workflow
  2. the 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:

  • build/version docker images in top level
    • Start versioning fv3net for the purposes of building docker images
    • Move docker image construction for a prognostic_run and fv3net images to the /docker folder.
    • Delete the old contents of /docker which seem obsolete (last touched Oct 2019).
    • add rules make push_images and make build_images
    • Update the README.md
    • updated yamls in workflow directories
  • move workflows/prognostic_c48_run/online_modules into fv3net/runtime. This module will now be available to other workflows.

Todo:

  • rerun diagnostics workflow in argo
  • rerun full end to end pipeline

@nbren12 nbren12 changed the title Refactore fv3 runtime modules and image construction Refactor fv3 runtime modules and image construction Mar 17, 2020
@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

Currently getting this error:

$ argo logs prognostic-run-diags-mtrbs-3453690810                                                                                                                                                               (fv3net)
Traceback (most recent call last):
  File "/opt/conda/envs/fv3net/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/opt/conda/envs/fv3net/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/jovyan/fv3net/fv3net/pipelines/save_prognostic_run_diags.py", line 75, in <module>
    resampled = ds.resample(time="3H", label="right").nearest()
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/resample.py", line 125, in nearest
    return self._upsample("nearest", tolerance=tolerance)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/resample.py", line 60, in _upsample
    return self._obj.reindex(method=method, *args, **kwargs)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/dataset.py", line 2483, in reindex
    **indexers_kwargs,
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/dataset.py", line 2514, in _reindex
    sparse=sparse,
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/alignment.py", line 546, in reindex_variables
    int_indexer = get_indexer_nd(index, target, method, tolerance)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/core/indexing.py", line 103, in get_indexer_nd
    flat_indexer = index.get_indexer(flat_labels, method=method, tolerance=tolerance)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/pandas/core/indexes/base.py", line 2740, in get_indexer
    indexer = self._get_nearest_indexer(target, limit, tolerance)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/pandas/core/indexes/base.py", line 2820, in _get_nearest_indexer
    left_distances = np.abs(self[left_indexer] - target)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/coding/cftimeindex.py", line 444, in __sub__
    return CFTimeIndex(np.array(self) - other)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/coding/cftimeindex.py", line 248, in __new__
    assert_all_valid_date_type(data)
  File "/opt/conda/envs/fv3net/lib/python3.7/site-packages/xarray/coding/cftimeindex.py", line 208, in assert_all_valid_date_type
    "objects. Got object of {}.".format(date_type)
TypeError: CFTimeIndex requires cftime.datetime objects. Got object of <class 'pandas._libs.tslibs.timedeltas.Timedelta'>.

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

@spencerkclark ^^^^ seems up your alley. Thoughts?

@spencerkclark
Copy link
Member

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.

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

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.

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

I think I've been in dependency hell a lot lately.

@spencerkclark
Copy link
Member

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.Index. We made changes in xarray to address this, but we haven't issued a release yet.

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).

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

Yah. I think this is unavoidable when using open source tools, honestly I put the blame on conda for not having a great version "locking" solution like poetry or pipfile. With that it would much easier to pin our versions without over-specifying the environment.yml.

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 17, 2020

It's just annoying that I've burned by upstream dependencies of our dependencies twice in two days.

@nbren12
Copy link
Contributor Author

nbren12 commented Mar 18, 2020

Copy link
Contributor

@frodre frodre left a 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_%:
Copy link
Contributor

Choose a reason for hiding this comment

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

Neat. 🤩

Makefile Outdated Show resolved Hide resolved
Copy link
Contributor

@oliverwm1 oliverwm1 left a 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():
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@nbren12 nbren12 merged commit 598cb26 into master Mar 21, 2020
@nbren12 nbren12 deleted the refactor/fv3net-online-modules branch March 21, 2020 00:24
spencerkclark pushed a commit that referenced this pull request May 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants