+1 for cutting 0.1-incubating and starting these changes in 0.2.
-- Joyce On Wed, Jun 5, 2013 at 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 > >
