This sounds like a good path to proceed down to me. I would formulate the below into a set of JIRA issues, then proceed by incrementally evolving the toolkit to support this.
The only catch is that many of these could potentially be API back compat. Since we haven't really talked or suggested about the impact of this; nee made a release, it's certainly possible to do this in trunk. My suggestion though since trunk represents what we all believe to be RCMET 2.0 API compat, we should probably create a branch for this. Or, better yet: 1. Close out current JIRA issues for 0.1-incubating. 2. Cut a 0.1-incubating RC/release process. 3. Start to implement the below in 0.2-incubating. Thoughts? Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Michael Joyce <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, June 5, 2013 6:56 AM To: dev <[email protected]> Subject: Proposed Toolkit Refactoring >All, > >This is a brief rundown of a discussion that Paul, Cam, Mazi, and I had >yesterday regarding the current state of the toolkit and proposed changes >that we would like to discuss with the list. > >We discussed adding a number of objects that should help simplify toolkit >usage. Below is a high-level rundown of our discussion. > >-- > >Dataset: Simple container object for a dataset. Provides helpers for >accessing relevant data (getLatsLons, getTime) and convenience functions >(writeToFile()). > >DataSource: Provides the user with helper functions for grabbing the data >that they want to evaluate. There's a RCMED module specifically for >grabbing RCMED data and a Local module for grabbing local data. This could >easily be expanded to include ESG and other data sources. > >DatasetProcessor: Any operation that needs to be run on datasets (that >isn't the evaluation obviously) is found in the DatasetProcessor. It >supports: >- regridding (spatial and temporal) > - masking/cleaning/filtering >- subsetting (spatial and temporal) >- ensemble generation > - anything else that fits here. > >Evaluation: The Evaluation object is (surprise surprise) in charge of >running Evaluations. It keeps track of the datasets (both 'reference' and >the 'targets') that the user wants to use in the evaluation. It runs all >the necessary evaluations and keeps the results nicely stored and readily >accessible for the user. > >Metric: Metrics are added to an Evaluation and used during the run. All >metrics inherit from the base Metric class. All you need to add new >metrics >is inherit from Metric and override the 'run' method. > >Plotter: The Plotter makes result visualization a breeze. If you give it >an >Evaluation object it will spit >out plots of all the results. Give it a Dataset and it will spit out a >plot. You can even have it return >Matplotlib objects so you can make your results look exactly the way you'd >like. > >-- Joyce
