issue_comments

Ah, thanks very much! I'll switch to using that syntax instead.

I apologize for this slight tangent but it's related to why we use sets in drop(). Is there a good way in xarray to only keep a list of variables? Our approach is to create a set of all variable and subtract from it a set of variables we want to keep and to drop the resulting set of variables we don't want to keep. But it's hard for me to imagine others don't also need this functionality.

Additionally, I think we have a documentation bug: I can't reach the documentation on drop.

Yes, I noticed that, too. I assumed it wasn't being documented anymore because it was considered deprecated.

@dcherian - are you suggesting that @xylar change his downstream code to use drop_vars instead? drop_vars has been deprecated. I don't think that's the right response here.

I'm confused. In 0.14.1, drop_vars seems to have just been introduced and drop seems to have been dropped.

How about drop_vars instead?

Yes, I switched to drop_vars but first I had to make a new build of my conda package that constrains the dependency xarray <0.14.0 because it's broken with 0.14.1. So that's why I'm concerned. I have to do a new release before this fix propagates to my users.

So @rabernat and @dcherian, please clarify if I should be switching to drop_vars or if I am going to run into issues yet again if I do so?

I believe a set() object should be a valid labels argument according to the documentation of drop(): http://xarray.pydata.org/en/v0.14.0/generated/xarray.Dataset.drop.html#xarray.Dataset.drop

I think this might be a dask/numpy issue and probably unrelated to xarray: https://github.com/dask/dask/issues/4378

I'll close this but others can re-open if need be.

@zxdawn, I was able to verify that, by adding decode_times=False to your code, I get: ``` keys of merge: odict_keys(['lon', 'lat', 'temperature', 'time'])

time of merge: <class 'netCDF4._netCDF4.Variable'> int64 time(time) units: hours since 2015-01-01 unlimited dimensions: current shape = (6,) filling on, default _FillValue of -9223372036854775806 used ```

Depending on your needs, you might be able to get away with calling open_mfdataset with decode_times=False. This should leave your time coordinate as it is (i.e. integer hours since 2015-01-01) but that will limit the types of operations you can do on the time dimension because it will not be converted to some kind of DateTime object. For example, it would be difficult to do time averaging that is aware of months, years, etc.

Hmm, I agree that it shouldn't be hard but I don't really have time to do this right now. If no one has had a chance to look into it by mid May I might be able to take it on then.

@rabernat, your suggestion above has worked perfectly to get our unit tests working again in MPAS-Analysis so that will tide us over until this issue can be addressed directly in xarray. Thanks!

Yes, I think that's exactly right.

Yes, true. I'm trying to think if there are any examples where the fixed-in-time variables would not be coordinates. So far, none come to mind. Thanks for the tip.

@rabernat, so you're fooling xarray into not including the time dimension in your non-time variables by making them coordinates in the above example?

@shoyer, I stand corrected. in 0.10.1, I also see the Time variable getting added to refBottomDepth when I open multiple files. So maybe this is not in fact a new problem but an existing issue that happened to behave as I expected only when opening a single file in previous versions. Sorry for not noticing that sooner.

@shoyer, in that case as well, Time is added to refBottomDepth in v 0.10.3, which was not the case in previous xarray versions.

cc @pwolfram