+1, on the better yet. --Paul
On 6/5/13 7:19 AM, "Mattmann, Chris A (398J)" <[email protected]> wrote: >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 >
