Basic idealized case support

[spencerkclark]

It appears the bare minimum changes required to read in an idealized case are:

1. Exception handling for 'NO_CALENDAR' specifications in netCDF file metadata. A solution is to default to a '360_day' calendar type. Without any further modifications this is somewhat dangerous, since one can then make monthly or seasonal climatologies (that are meaningless). However, implementing non-standard calendar support is likely a bit over our heads at the moment (at the very least outside the scope of aospy; see Non-standard Calendar Support numpy/numpy#6207, Return numpy.datetime64 arrays for non-standard calendars pydata/xarray#126, Support or default to less detailed datetime64 pandas-dev/pandas#7307). The pandas issue link interestingly explains why datetime64 (by default) can only support going back to 1678.
2. Exception handling to allow a Model / Run to be read in without a set of interpolated pressure levels. In other words, allow for a case which only uses the model vertical coordinates.

Past that, along with these changes, if one uses the one_dir file read in mode, things work reasonably well. For example this is a Run object that works for a 720-day idealized model run.

variables = ['olr', 'temp', 'sphum', 'ps']

idealized_moist_control = Run(
    name='idealized_moist_control',
    description=(
        'A test case for using aospy + an idealized simulation.'
        ),
    direc_nc='/path/to/output',
    nc_dur=2,
    nc_start_yr=0,
    nc_end_yr=1,
    default_yr_range=(1,1),
    nc_dir_struc='one_dir',
    nc_files={v : '00000.1x20days.nc' for v in variables}
)

Ideally one would be able to specify the time ranges in units of days rather than years. That's something we may want to work on in the future. This would be important in a case where the period of analysis does not align well with multiples of 360 days. (In this case it's OK since the period is days 361 to 720).

[spencerahill]

This looks great overall. A couple thoughts:

1. Will you create an Issue re: support for duration in days? I agree it should be implemented at some point.
2. In implementing support for data held in GFDL repos (see /archive/pcmdi/repo/{obs4MIPs,ana4MIPs,CMIP5}), I changed the model grid attribute setting routines in a way that overlaps with your changes. Now, within Model._set_mult_nc_grid_attr, if the desired array isn't found in any of the nc_grid files, the corresponding attribute is assigned None.
3. (Minor point) re: the deleted line in io.py, I am trying to follow the PEP8 style conventions, which specifies two blank lines following the last import statement. Emacs has a nice built-in syntax checker, flycheck, which -- after getting properly configured -- issues warnings about such things.
4. Nice usage of the warnings module. I think there is a lot of room for using the standard library much more extensively throughout aospy...it has donned on me over the past month or so just how much of the code I've written is just hackish versions of already built-in functionality (and that's not even including xray)!

[spencerkclark]

Great -- I'm glad it worked out! Thanks for the feedback as well. Regarding your thoughts:

1. For sure, I'd be happy to write an Issue regarding the time bound specifications.
2. Very good, I'll test it out just to make sure, but that's probably a more elegant solution than what I did to handle it.
3. Thanks for pointing me to the emacs flycheck package for checking PEP8 style guidelines. I appreciate you holding tightly to those. Sorry I was a bit careless in the io.py file -- I had initially issued a warning in the module, but realized it was unnecessary; when I deleted the import warnings statement there I didn't pay attention to the line spacing. I'll try and be more careful in the future.
4. Although I'm not super familiar with the intricacies of warnings, it seemed like the most natural thing to do in that situation. I will say that it still is a bit inflexible in that it doesn't help in the case when the calendar attribute is not recognized and you don't want to use a 360_day calendar. There's probably some room for improvement there as well.