-
Notifications
You must be signed in to change notification settings - Fork 8
Conversation
esmlab/core.py
Outdated
|
||
if self.time_bound is not None: | ||
ds[self.tb_name].data = self.time_bound.data | ||
self.time_bound[self.time_coord_name].data = groupby_coord.data | ||
ds[self.tb_name] = self.time_bound |
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.
maybe keep .data
on the RHS so that any attributes are not overwritten
When you get a chance, can you take a look at this? and if everything looks good, please merge it. |
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 don't know the code that well at all (!) but this stuff looks sane.
I would add xarray.testing._assert_internal_invariants(dataset_or_dataarray)
in your tests to be sure that you're creating valid xarray objects.
@@ -504,9 +493,9 @@ def compute_mon_anomaly(self, slice_mon_clim_time=None): | |||
# reset month to become a variable | |||
computed_dset = computed_dset.reset_coords('month') | |||
|
|||
computed_dset[self.time_coord_name].data = self.time.data | |||
computed_dset[self.time_coord_name] = self.time |
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.
keep .data
on RHS? But it seems like you're rewriting attributes later, in which case this might not matter.
@@ -156,9 +156,8 @@ def test_mon_climatology(ds_name, decoded, variables, time_coord_name): | |||
ds = esmlab.datasets.open_dataset(ds_name, decode_times=decoded) | |||
esm = ds.esmlab.set_time(time_coord_name=time_coord_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.
is esm
an xarray object, if so use xarray.testing._assert_internal_invariants(esm)
to make sure you aren't breaking any assumptions
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.
esm
here is an instance of esmlab.core.EsmlabAccessor
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.
so check esm._ds
?
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.
so check esm._ds?
Done.
I myself have started having a hard time understanding the existing codebase. It's been a while since I looked at esmlab's code base. So, I spent the last four days looking at the existing code base, and my take-away is that esmlab's codebase is full of hacks. And this makes it difficult to debug or even maintain :( I am personally in favor of helping with pushing most of the general functionality into xarray and only keeping things that are domain-specific. I just found out that there has been recent progress in pydata/xarray#2922, and I am excited about this. Once pydata/xarray#2922 is merged, we can move most if not all existing functionality from https://github.com/NCAR/esmlab/blob/master/esmlab/statistics.py into xarray. |
Yeah +1 on moving things upstream. From a quick look, it seems like esmlab basically adds time-aware weighted groupby/resampling; time bounds consistency; and time units/calendargpropagation (pydata/xarray#1614). For the last one, it would be good to document how much of the table in pydata/xarray#1614 is implemented and what's left. |
Thank you, @dcherian! I am merging this for the time being. |
@andersy005 , f3a548d breaks the code snippet from #155 for me:
I get the following:
|
@andersy005 , if I revert the following change within f3a548d, then the code snippet from #155 runs with no error
I don't understand how this codes fits in with the rest of esmlab, so I'm unable to comment more productively. |
@klindsay28, sorry for the breaking changes :(. I should have tested this PR against your example prior merging, The existing tests need further improvement to make sure that we are testing the most common use cases. I am going to look into this and will open a PR with a fix for this. |
Fixes #155
Fixes #154