issue_comments

I followed data = True / False / "array" / "list"

Making all the requested changes, the above should resolve momentarily.

I like this "trick"/suggestion:

And a design question/suggestion: what about instead of adding another kwarg, you could use data = True / False / "numpy"?

I will implement this if we are in agreement with @dcherian

I'm happy to "fix" the mypy issues, but it's on that I suspect might be requested for changes (if I recall correctly, it's just in the tests)

i kinda implied, but I'll just state that the extra code to test equality of encodings is not handsome.

@dcherian thanks! I didnt incoroprate any suggestions yet. regarding the inequality of encodings of datasets is obscured by assert_identical(a, b) not evaluating encodings. it seems like it should have an option to also check encodings (or not).

In the off-hand chance this is reviewed before I push again, do not merge. I have a fix to encodings not getting properly roundtripped in Ds.from_dict(ds.to_dict). it was minor to fix but making sure it's tested will take a min

I solved the mypy errors in a highly dubious way. 👀

I would appreciate any edification on the Mypy failures. Looking at the indicated lines, i'm 🤷 .

The PR #7739 is available for review. @jhamman @dcherian would be my choices. i think this is pretty straight forward. I suppose the name of the kwarg being numpy_data is debatable. I based this on the discussion of numpy vs tolist above, preferring the former but acknowledging the comment that a package name as an arg is odd. Could do as_numpy or something slightly different.

I'd be interested in reviving this, this is exactly what I want to achieve. It's not clear if there was some reason this never went ahead. I looked around but didnt find anything. LMK if it there's some reason not to pursue it. THanks

🎊

There were easy patterns to follow for this, so I just went for it. @dcherian Are the failures fixable? I'm not sure what to make of them.

I should add that changing the encoding on the variable itself was not "an easy detail". The basic thing I tried was unsuccessful, so if this is desired some more work is needed.

I guess the additional documentation would go here. http://xarray.pydata.org/en/stable/io.html#writing-encoded-data If we decide to keep the "gnarly" warning message, we should probably do a bit of explaination here.

@dcherian Thanks,

First, I think you're right that the encoding['contiguous']=True is coming from the input file. That was not clear to me (and I did not read the xarray code to verify). But it makes sense.

Second, my example shows something more slightly complicated than the original example which was also not clear to me. In my case the unlimited dimension (time) is chunked and is being successfully written in both cases (before and after work around). The error/ failure is happening on the a variable that contains the unlimited dimension but which has encoding['contiguous']=True for the variable.

This makes sense upon a slightly more nuanced reading of the netcdf4 manual (as quoted my markelg)

"contiguous: if True (default False), the variable data is stored contiguously on disk. Default False. Setting to True for a variable with an unlimited dimension will trigger an error."

The last sentence apparently means that for any variable with an unlimited dimension the use of contiguous=True triggers an error. That was not clear to me until I looked a bit harder at this. I think that slightly refines the strategy of how to deal with the problem.

I propose that the solution should be both a) delete encoding['contiguous'] if it is True when asked to write out a variable containing an unlimited dimension. b) raise an informative warning that the variable was chunked because it contained an unlimited dimension. (If a user hates warnings, they could can handle this deletion herself. One the other hand, there's really nothing else to do, so I'm not sure the warning is necessary... I dont have strong opinion on this, but the code is fiddling with the encodings under the hood, so a warning seems polite).

A final question: should the encoding['contiguous'] be removed from the xarray variable or should it just be removed for purposes of writing it to ncdf4 on disk? I suppose a user could be writing the xarray dataset to another format that might allow what netcdf does not allow. This should be an easy detail.

I'll make a PR with the above and we can evaluate the concrete changes.

Here's what I understand so far. For my file, i write it with ("ensured") and without ("unensured") the workaround (actually @markelg for discovering this).

(base) jamesmcc@cheyenne3[1021]:/glade/scratch/jamesmcc/florence_cutout_routelink_ensemble_run/ensemble> grep '_Storage' ensured_ncdsh.txt feature_id:_Storage = "contiguous" ; latitude:_Storage = "contiguous" ; longitude:_Storage = "contiguous" ; time:_Storage = "chunked" ; member:_Storage = "contiguous" ; crs:_Storage = "chunked" ; order:_Storage = "chunked" ; elevation:_Storage = "chunked" ; streamflow:_Storage = "chunked" ; q_lateral:_Storage = "chunked" ; velocity:_Storage = "chunked" ; Head:_Storage = "chunked" ; (base) jamesmcc@cheyenne3[1022]:/glade/scratch/jamesmcc/florence_cutout_routelink_ensemble_run/ensemble> grep '_Storage' unensured_ncdsh.txt feature_id:_Storage = "contiguous" ; latitude:_Storage = "contiguous" ; longitude:_Storage = "contiguous" ; time:_Storage = "chunked" ; member:_Storage = "contiguous" ; crs:_Storage = "chunked" ;

The error that is thrown is, just the tail end of it:

``` /glade/p/cisl/nwc/jamesmcc/anaconda3/lib/python3.7/site-packages/xarray/backends/netCDF4_.py in prepare_variable(self, name, variable, check_encoding, unlimited_dims) 466 least_significant_digit=encoding.get( 467 'least_significant_digit'), --> 468 fill_value=fill_value) 469 _disable_auto_decode_variable(nc4_var) 470

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Dataset.createVariable()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Variable.init()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4._ensure_nc_success()

RuntimeError: NetCDF: Invalid argument ```

If I go to line 464 in xarray/backends/netCDF4_.py, I see that the variable it is failing on is crs. If I

print(name) crs encoding.get('contiguous', False) True but the ncdump -sh shows it's actually chunked. I'm not sure this is exactly what's raising the error down the line, but these two things seem to be at odds.

My current question is "why does encoding.get('contiguous', False) return True?"

If you have any insights let me know. I probably wont have time to mess with this until next week.

I could be persuaded.

I just dont understand how 'contiguous' gets set on the encoding of these variables and if that is appropriate. Does that seem obvious/clear to anyone?

I still dont understand why this is happening for me. I made some fairly small modifications to some code that never threw this error in the past. The small mods could have done it, but the identical code on my laptop did not throw this error on a small sample dataset. Then I went to cheyenne, where all bets are off!

I apparently have this problem too. Thanks @gerritholl for the workaround.

🤦‍♂️ with that formatting in the whats-new.rst. (a reminder to squash) I think this is complete. thanks for the mini tour of xarray internals, I learned some useful things!

🎊

I'm uncertain why travis is failing. Two of them look http-related and the other maybe be docs-related (but dont trust me). Running pytest locallin in the xarray/tests/ dir ============== 7007 passed, 1170 skipped, 25 xfailed, 1 xpassed, 30 warnings in 62.12 seconds ==============

@shoyer Added test and documentation. I did not build documentation, wasnt sure if that was necessary. The history should be squashed when the time comes...

thanks, @shoyer. I will add the documentation and tests now that the first hurdle is cleared and update the PR.