Expand testing on to_netcdf4

[rstoneback]

Is your feature request related to a problem? Please describe.
to_netcdf4 failed for DMSP, #567. The underlying issue had been present for some time but nobody on the team tried to make a netcdf4 file from Madrigal data.

Describe the solution you'd like
We should include a to_netcdf4 test in the generalized testing so that all instruments are known to work.

Describe alternatives you've considered
Leaving support for exporting data to netcdf4 untested across the pysat family is certain to leave bugs in the works.

Additional context
Add any other context or screenshots about the feature request here.

[jklenzing]

I suspect this requires sorting out #60 first. I ran into issues writing from xarray objects, which is why xarray has its own unit tests for this rather than just inheriting from pandas.

[jklenzing]

Once #896 is sorted out, we can start testing this out.

[jklenzing]

What should success for this test look like? Is it

• load existing data
• write a copy of this using pysat's netcdf interface
• load the new data and compare to the old?

[aburrell]

The existing tests already do that. A good place to start would be coveralls, to see what is and isn't covered by the current tests.

[rstoneback]

We currently test that we can load all kinds of public datasets, we don't test that we can write those datasets using to_netcdf. In essence, we need to review all the metadata that we load.

[JonathonMSmith]

I may not be in the right place, but to_netcdf is not working for cnofs IVM either.
in:

import pysat
import datetime as dt
ivm = pysat.Instrument(platform='cnofs', name='ivm')
d1 = dt.datetime(2012,1,1)
ivm.load(date=d1)
ivm.to_netcdf4('./ivmdat.nc')

returns:

out: TypeError: object of type 'float' has no len()

This appears to happen on line 1440 of pysat.utils.io when pysat.utils.io.return_epoch_metadata trys to take len of the epoch units which happen to be nan in this case. It seems like this statment is here to test that the dict value is empty. Unless it's likely that this value will be [], maybe instead of len the function could use == ''.

[aburrell]

There should probably be a type check on the meta data. Under all of this is the assumption that units are a string. Since we allow the types to be updated, we need to check that this is, indeed, the case.

[jklenzing]

Unless it's likely that this value will be [], maybe instead of len the function could use == ''.

I think this is the right call. a list is not allowed in meta.

[jklenzing]

Given the number of changes/testing we would need to make in the libraries to implement this, I propose we bump the milestone.

[jklenzing]

Bumping the milestone since this requires extensive testing with downstream packages.