A few clarifying updates to the design doc.

Author: xylar

design_docs/generalize_calendar.md

@@ -52,7 +52,7 @@ between two dates) and of making plots that are consistent with these calendars.
 
 <h2> Requirement: The 'Time' coordinate of xarray data sets must support at least years 
 0001 and 9999, and preferably any conceivable value<br>
-Date last modified: 2017/02/09 <br>
+Date last modified: 2017/02/16 <br>
 Contributors: Xylar Asay-Davis
 </h2>
 
@@ -94,8 +94,8 @@ performed with the calendar-aware functions `netCDF4.date2num` and
 (for efficiency and simplicity of calling code) in addition to single values.
 
 Curve ploting can be supported with `matplotlib.pyplot.plot_date`, which takes a date
-of exactly the format used here (days since 0001-01-01), which was part of the reason
-for choosing this format for the date.
+of exactly the format used here (days since 0001-01-01).  The compatibility with `plot_date`
+was part of the reason for choosing this format for the date.
 
 <h2> Design solution: The 'Time' coordinate of xarray data sets must support at least years 
 0001 and 9999, and preferably any conceivable value<br>
@@ -106,14 +106,14 @@ Contributors: Xylar Asay-Davis
 Same as above. In theory, the use of days since 0001-01-01 would allow any year
 to be supported, not just the range from 0001 to 9999.  However, the conversions
 to `datetime.datetime` objects for mathematical manipulation will constrain
-the dates to be between datetime.min (0001-01-01) and datetime.max (9999-12-31).
+the dates to be between `datetime.min` (0001-01-01) and `datetime.max` (9999-12-31).
 
 
 <h1> Design and Implementation </h1>
 
 <h2> Implementation: The 'Time' coordinate of xarray data sets must be consistent
 with the MPAS calendar <br>
-Date last modified: 2017/02/11 <br>
+Date last modified: 2017/02/16 <br>
 Contributors: Xylar Asay-Davis
 </h2>
 
@@ -131,18 +131,19 @@ from ..timekeeping.utility import string_to_days_since_date, \
     days_to_datetime, datetime_to_days
 ```
 **This violates the first requirement in the 
-[MpasXarray class design doc](https://github.com/xylar/MPAS-Analysis/blob/design_doc_variable_mapping_reorg/design_docs/mpas_xarray_class.md).
+[Design Document: Moving variable mapping out of mpas_xarray](https://github.com/xylar/MPAS-Analysis/blob/design_doc_variable_mapping_reorg/design_docs/variable_mapping_reorg.md).
 I am open to alternative solutions for keeping `mpas_xarray` separate from the rest
 of analysis but these 3 functions do not conceptually belong in `mpas_xarray`.  The
 problem is exacerbated by the fact that there are analysis-specific functions in
 `timekeeping`, meaning that this cannot easily be made a submodule of `mpas_xarray`
 (nor would this make very much logical sense).  Having 2 `timekeeping` modules, one
 for `mpas_xarray` and one for MPAS-Analysis, seems unnecessarily confunsing.**
 
-The methods and helper functions named `open_multifile_dataset` haave been updated
-to use this method for parsing times.  This involves removing the `year_offset` argument
-and adding an optional `simulation_start_time` argument for supplying a date to use to
-convert variables like `daysSinceStartOfSim` to days since 0001-01-01.
+The functions `generalized_reader.open_multifile_dataset` and
+`mpas_xarray.open_multifile_dataset` have been updated to use this method for parsing
+times.  This involves removing the `year_offset` argument and adding an optional 
+`simulation_start_time` argument for supplying a date to use to convert variables
+like `daysSinceStartOfSim` to days since 0001-01-01.
 
 An example of opening a data set and manipulating times withe the new approach in
 the OHC script is:
@@ -279,16 +280,13 @@ Date last modified: 2017/02/11 <br>
 Contributors: Xylar Asay-Davis
 </h2>
 In [xylar/generalize_calendar](https://github.com/xylar/MPAS-Analysis/tree/generalize_calendar), 
-unit testing has been added for timekeeping and mpas_xarray and MpasAnsalysisXarray that checks
-both the `gregorian` and `gregorian_noleap` calendars under simple test conditions.  However, we
-have no data sets that test `gregorian`, so we have a somewhat limited ability to test this 
-calendar option.  Fortunately, there are also no immediate plans to run with `gregorian`.
-
-I have tested that the results (except `regriddedSeaIceConcThick`, which I'm not able to run on my
-laptop) of a G240km ACME test case are bit-for-bit identical to those from `develop`. 
+unit testing has been added for `timekeeping` and `mpas_xarray` that checks both the `gregorian` 
+and `gregorian_noleap` calendars under simple test conditions.  However, we have no data sets 
+that test `gregorian`, so we have a somewhat limited ability to test this calendar option.
+Fortunately, there are also no immediate plans to run with `gregorian`.
 
-I will make sure all tests with config files in the configs/lanl directory produce bit-for-bit 
-results with the current develop.
+I will make sure all tests with config files in the `configs/lanl` and `configs/edison` 
+directories produce bit-for-bit results with the current `develop`.
 
 <h2> Testing and Validation: The 'Time' coordinate of xarray data sets must support at least years 
 0001 and 9999, and preferably any conceivable value<br>
@@ -300,5 +298,6 @@ Unit tests have been added to ensure that dates both close to 0001-01-01 and typ
 calendar dates (e.g. 2017-01-01) function as expected.
 
 @akturner's MPAS-SeaIce run with real dates (mentioned in 
-[#81](https://github.com/MPAS-Dev/MPAS-Analysis/issues/81))  will also be analyzed to make sure
-we are supporting a range of years starting in 1958.
+[#81](https://github.com/MPAS-Dev/MPAS-Analysis/issues/81))  has been successfully
+run with the proposed approach.  This run started in 1958, and had presented a problem
+for MPAS-Analysis with the previous calendar.