Use netcdf rather than scipy as to_netcdf engine

[spencerahill]

Closes problem described in #232 (comment) and more properly diagnosed in remainder of that thread.

[spencerahill]

@spencerkclark does this look good? (assuming Appveyor passes; currently running. Travis has passed.)

I'll flesh out the What's New and merge once we're green

[spencerkclark]

@spencerahill thanks for putting this together! I'm not sure what is going on in the Appveyor Python 3.4 environment, but maybe removing the line I suggest will fix things. It looks like it's installing some pretty old versions of most of the libraries (possibly because of that added requirement).

[spencerkclark]

Do you think we can remove this now too?

[spencerahill]

Good call, let's see what that does.

(FYI I might have to run for the night before this finishes. If so I'll return to it tomorrow.)

[spencerkclark]

Huh, it seems like scipy gets installed anyway in the rest of the environments, so maybe we should just keep them the way they were? I'm assuming things will still pass in that case.

Note also this error in our xarray-dev build:
https://travis-ci.org/spencerahill/aospy/jobs/303816476#L892

[spencerahill]

Note also this error in our xarray-dev build

Ah, so I suspect what's going on is: in our other environments, xarray is installed via conda, and it's conda recipe includes scipy. But in this case, that doesn't happen.

This was a good catch -- if we're actually going to switch from scipy to netCDF, we'll have to do so in our open_dataset and open_mfdataset calls also, lest xarray chooses scipy by default and it's not there. But then when I tried to add engine='netcdf4' to all of those calls, I got a bunch of errors when I ran our tests locally.

Ultimately it's very hard to imagine a user not having scipy, so I don't mind retaining it as a dependency after all. So I just pushed a commit reverting to including it, while still keeping the engine='netcdf4' in the lone to_netcdf call.

As for the AppVeyor 3.4 failures, I'm not sure why there would be the day vs. nanosecond mismatch. I'm hoping they'll go away with this commit.

[spencerahill]

Blarg. Still one AppVeyor failure, strangely in the 3.5 environment and only on the "branch" rather than "pr" tests. (Since the aospy repo is under my profile, whenever I submit a PR, the CI gets triggered twice: once for the new commits on a branch in my repo, and once for a PR. When others submit a PR, only the PR tests run).

Log for that failure is here: https://ci.appveyor.com/project/spencerahill/aospy/build/1.0.390/job/n8yuaforvylotr9q

Will have to leave it at that for now; have to run for the day. But we're at least getting close.

[spencerahill]

One last thing: closing and reopening to retrigger the tests, to see if that was a one-off failure.

[spencerahill]

Ok that did not retrigger them...will return to tomorrow

[spencerahill]

@spencerkclark thanks for the assist

Very odd. Two failures in a row on the AppVeyor "branch" tests, but not on the "pr" tests, and only in 3.5 in the first case and only in 3.4 in the second case. Although the error is the same in both cases (here and here), on test_submit_two_calcs in the cases where parallelize=True but not where 'parallelize=False.

Given the inconsistency, I'm going to go ahead and merge this, in hopes that this was a one-off. But I'm not entirely convinced that this isn't pointing to some occasionally fragile logic on our side. So we'll keep monitoring for similar problems.

[spencerahill]

Oy vey, now both 3.4 and 3.5 are failing. Will need to come back around to this, have to turn to other things for now.