3/30/04 16:14 1 Lessons Learned CERES Data Management Presented to GIST 21 “If the 3 laws of climate are calibrate, calibrate, calibrate, then the 3 laws of data management are communicate, communicate, communicate.” Anon. April 1, 2004

3/30/04 16:14 2 Presentation Objectives Document experiences in CERES Data Management (DM) that might be useful in releasing GERB data products –Data Release –Metadata –End user support Foment discussion –CERES wants to learn from your experiences, as well

3/30/04 16:14 3 CERES DM Lessons Learned Data Products Design Affects Release Data products are designed by the instrument team, not the end users –Inherent flaws from the end user point of view –Involve end users as early as possible –Ask yourself what you liked/disliked about products you have used Good Software Engineering is critical to code success over lifetime –Compartmentalize dependencies to permit maintainability Minimize hardware and compiler dependencies –Satellite and specific instrument dependencies in configuration files –Separate scientific algorithms and data management functions Naming Conventions for Data Sets –Make it intuitive –Maturity/scientific quality as well as contents Data Product format should be well documented –Make it easy for the consumer to use the data –CERES sample read-packages provide working code, samples

3/30/04 16:14 4 CERES DM Lessons Learned Data Production Ensure development and production platforms are identical to avoid surprises Re-processing is never considered early enough –Processing and re-processing are different production considerations –Long duration observations evolve over their lifetime Inputs change, algorithms improve Hardware, compilers and operating systems evolve –Climate data records necessitate highly stable data products Need consistent processing conditions to avoid introducing biases –PI’s always want re-processing done quickly (10x) Target for CERES is to fully re-process the entire collection in 1 year Monitor ingest for missing data elements –Prepare production control to test for missing data and avoid running without it –Late delivery of data products –Look for opportunities to substitute for missing data in production stream –Prepare for discovery of bad data after months of ingest

3/30/04 16:14 5 CERES DM Lessons Learned Data Release Process Two release processes targeting different audiences Science Team “release”: ValRx to evaluate Production data –QC to avoid processing and distributing bad data or algorithms Public Release requires careful consideration –Make Public Release a formal process PI & Science Team approval –Any public release should be a complete package Assessment of maturity and quality (Quality Summary) Tools to make it easy to use (sample read package) End user data collection, agreements and notices –What is the value of data being published? Early peer review often detects systematic problems that developers do not see Use in assimilation for modeling? Cross-calibration? Stakeholder value to claim credit for accomplishment and a basis for future funding? Final data set for long term use by unexpected users?

3/30/04 16:14 6 CERES DM Lessons Learned Data Product Distribution Process CERES distribution is constrained by size of data products Make data products easy to obtain and use by the consumers Do not withdraw data products if used in publication –Even if there are errors –If they should not be used in publication, make that clear Make delivery as flexible as possible to make data useful –Subsetting, based on time and geography Pre-formatted data products are often huge –Users often don’t have means of locally subsetting the data –Size impacts customer response time and cost of distribution Networks and physical media can impact customer satisfaction Require registration to obtain data products –Request notification if data products are re-distributed

3/30/04 16:14 7 CERES DM Lessons Learned Post-delivery User Support Communicate, communicate, communicate –Make customers interested in your future –Be proactive about communicating problems when they are discovered –Ask for feedback about their use of your data –Obtain acknowledgement of use in publication Citation searches by a library, etc Request users to provide a copy of papers in which your data is used Stakeholders always ask for some proof of use Good documentation can reduce the interactive user support –Both format and science quality –Separate technical support for accessing the data products from the science –Sample Read Packages to help Users use it Permit them to get to data quickly