EMU Toolbox: Current Improvements, Bugs, and Desirable Features

This is a list of current tasks or potential problems, and desirable features to be implemented or considered sometime in the future. The order does not reflect the order of priority.

• Exchange of code files. What do we do so that we don't screw up our preferred text layout/format?? eg, I don't like using tabs, I use 2 blank spaces for each level of indentation.
• netCDF libraries. We should make it a goal for EMU v1.0 to upgrade all NC functions to the v3.4 API.
• Handling Masks. Some features that should be added: capability to use netcdf masks; capability to handle float-type masks. Also, add a feature where for a particular variable the global mask will be ignored, and instead (if it's a netcdf file), the FillValue from the variable will be used to define the mask of the variable.
• Make EMU and related apps "Year 2000" compatible.
• Handling/recognizing Aggregated Time axes. Make sure Annual and MonthlyMean data can be used seamlessly as input. Monthly means (climatology), annual means, and other such axes currently are interpreted as such by specifying an appropriate variable argument in the config file (parsed by the function TimeType() ). Maybe we should adopt a convention, at least for netcdf files, where a specific attribute will be added to the time coordinate variable, which says what kind of time axis it is; this attribute will then be read automatically by EMU. Note that to support Ferret, currently monthly mean NC files do use the time attribute: time:modulo=" " ; We could simply adopt this as our convention, use it consistently, add a similar convention for Annual Means. But we'll still need a convention for monthly means vs. monthly sums (OR SHOULD THAT BE LEFT AS AN INTERPRETATION THAT THE USER HAS TO MAKE??).
• Enhance memory allocation functions. It would be very useful if these functions, in addition to allocating memory to arrays, would have the *option* of initializing these arrays to a given value (to be entered as an *optional* argument!). These would require the use of variable arguments: if the initialization value is not included, the allocated array is returned uninitialized; if it is, it's returned initialized. Also, I'm not sure what the "GlobalDeallocation()" function does...
• Memory cleanup and ExitError(). Calls to ExitError() may cause problems if the memory that it tries to free hasn't actually been allocated. The only way of keeping track of what pointers have been allocated, is through the use of global flags throughout the toolbox, in Initialize(), etc; these flags will be set when each specific variable of interest is allocated memory, and then memory deallocation can be dependent on the state of the flag.
• If our EMU apps will not use the two local functions ProcessCommandLineArgs() and LocalCleanUp(), do we still need to define them in the app (as empty functions) ? Can we do something in the toolbox so that they don't *have* to appear in the EMU app?
• 2-d arrays for spatial maps. The code still hasn't implemented Bill's suggestion to use 2-d arrays for "spatial maps", instead of the stretched 1-d arrays (which require the use of "irev" and related things). Should we start the switch?
• Exploring support for other "data models"?? For example, a fourth dimension, especially depth/elevation, for oceanographic & atmospheric applications (and soil depth layers, if there are several); different channels of one satellite; likewise, different types of a single, composite variable (eg, the different carbon pools of CASA-BG); relational dbs/tables, analogous to the PT interface of HDF-EOS. We'll see what kind of feedback we get from the meeting with the PRISM people. In general, though, a flexible and open-ended 4th dimension may be an optimal solution; that option would allow us to support depth/elevation dimensions or satellite bands.
• Spatial lagging functions. Write a set of "spatial lagging" functions that can be used for such things as computing spatial auto-correlation, semi-variograms, etc.