e-research in support of climate science

Transcription

1 e-research in support of climate science Bryan Lawrence Rutherford Appleton Laboratory reporting the efforts of dozens of other folks in major international projects including, but not limited to BADC itself (Juckes, Pascoe^2, Stephens, Kershaw...) CMIP5 (Taylor, Stoufer) Metafor (Guilyardi, Stenman-Clark, Devine...), IS-ENES (Joussaume) Earth System Grid, Earth System Curator (Balaji, DeLuca, Foster, Middleton, Williams) (none of whom were consulted about the content of this talk) & The Global Organisation for Earth System Science Portals, and the new Earth System Grid Federation

2 Outline The Climate Data Problem The Data Deluge Volume, Heterogeneity and Choice Evaluating Australia in CMIP3 Climate Models & the problem with understanding the differences between models and the simulations they produce. A Brief introduction to Metafor An introduction to the CMIP5 Information Ecosystem Aims and objectives of CMIP5 Global problem: Global simulations simulated globally. Global Deployment of information systems. The Earth System Grid Federation. Bringing the information flow together A tour through the CMIP5 information implementation. Exascale Futures: Some snippets from UK and European strategy thinking Interesting problems ahead? Can we use the next generation of HPC? And if we can, what will we do with the data?

3 In the beginning: observations WMO Images: from J. Lafeuille, 2006 All linked up, with global data distribution. World Meteorological Organisation have been doing e-infrastructure for years!

4 Compare with Research Instruments Some fixed, many deployed in an ad hoc manner!

5 NERC Mobile Research Sensors Slide courtesy of Alan Gadian, NCAS

6 Simulation Data Deluge 8 PB 4 PB 2 PB BADC Figures courtesy of Gary Strand (NCAR)

7 and let's not leave out EO! Source: ESA GSCB Workshop June 2009

8 20th Century Reanalysis Using data collected under the umbrella of the Atmospheric Circulation Reconstructions of the Earth (ACRE) initiative Assimilating (only) surface observations of synoptic pressure, monthly sea surface temperature and sea ice distribution to produce Data available from Jan 1871 to 2008 from NOAA ESRL but: 1 GB/year/variable, 56 ensemble members (+mean and spread), 10 variables (there are more), 120 years = 70 TB...

9 Old Weather/New Results (Modern max & min over HMS Dorothea 1818 Brohan et al 2010)

10 and so to metadata/provenance Neither of the last two examples would be possible without metadata Ship logbooks with location, time, along with measurements (Actually the measurements themselves were metadata for the ship logs.) Station data with information about location and calibration But both demonstrate problems with lack of metadata too: How were those ship measurements made, and with what accuracy? Did that station move, and if so, did anyone write it down (movements often lead to discontinuities in data records) Research data systems generate a wealth of information, usually recorded for a specific task. But that information, with sufficient information, could be repurposed, reinterpreted, and reused but mostly isn't! The sheer amount of data can overwhelm one's ability to reuse if one cannot: Discover data, and Discriminate between similar datasets. Get at basic facts as to what was done, how, and why, and

11 Take Home Points (1) Lots of data out there From routine sensor networks (such as the met networks), and From ad hoc deployment of instruments, not to mention A huge variety of simulations. Data volume increasing exponentially (that's obvious, but pay attention to the units, scale matters!) Heterogeneity increasing (a different sensor on every lamp post?) Great science is done by reusing data collected both for specific purposes and for generic reuse. It's generally hard to reuse data, because ancillary information is not as well kept as the data (and often not even recognised as useful). It will be seen that costs (research time+ money) for handling big data are falling in new places (or at least places where historically we have failed to spend)

12 Climate 101 Observations (AR4 WG1 Fig.1.3) Projections (AR4 WG1 Fig10.4) all seems rather simple doesn't it? Nice consumable curves... Enough for mitigation policy perhaps, but enough for adaptation policy?

13 Climate Delving Deeper... IPCC Fourth Assessment Report: ( Not much agreement in AR4 No stipling) Spatial and temporal subsetting statistics over models...

14 So why was Australia not stippled? Interannual variability means that our projections need to start in the right state (and have the processes to capture that variability correctly). Model uncertainty means that we may not believe our model(s) (any or all) have the relevant resolution and/or physics to capture (all) important processes. Scenario uncertainty means that we are not sure of the impact of different economic and emission futures. (Australia is unlucky, some regions more predictable than others, global mean much more predictable than any region) So what were the salient differences between the models? (Forget looking at the code, these models have millions of lines of code each!) Internal Variability Scenario Uncertainty Model Uncertainty Hawkins and Sutton, Climate Dynamics, 2010 ( /s ) Global

15 ...and deeper: CMIP3: What models did what? AR4: WG1 Table 10.4 Rows: Models, and their output types. Columns: Experiments and Projections (Three layers of complexity: models, experiments, output each of which is itself complex)

16 Digression: What is a model? Lots of interesting models actually! So, can we discuss the difference between two models (and their families of submodels)? Image: from J. Lafeuille, 2006

17 FAR:1990 SAR:1995 TAR:2001 AR4:2007 AR5:2013

18 State of the Art: Model Comparison 1: Tabulate some interesting property (and author grafts hard to get the information ) Guilyardi E. (2006): El Niño- mean state - seasonal cycle interactions in a multi-model ensemble. Clim. Dyn., 26: , DOI: /s

19 State of the Art: Model Comparison Kharin et al, Journal of Climate 2007 doi: /JCLI Dai, A.,J. Climate 2006 doi: /JCLI : Provide some (slightly) organised citation material ( and BOTH author and readers graft hard to get the information)

20 State of the art: Model Comparison 3: Calculate and tabulate some interesting properties and bury in a table or figure Guilyardi E. (2006): El Niño- mean state - seasonal cycle interactions in a multi-model ensemble. Clim. Dyn., 26: , DOI: /s

21 Why does this information detail matter? surely a technical paper can make lots of technical references, and those in the know, are, in the know? By and large: the climate projections community is actually a group of communities: From next generation experimenters, to big GCM modellers, to regional modellers, impacts assessment modelling, to impacts and adaptation modelling. Information does not easily flow between communities!

22 We've already seen concepts: Experiments (e.g. specific scenario projections) Models, with specific (experiment dependent) Metafor: 2.2 M euro EC project to deliver Resolution & Grids a Common Information Model to document these concepts, particularly in the context of supporting the next IPCC assessment report. combinations of sub-component models for specific processes. Associated infrastructure to collect and view such documentation, and and Simulations Build an accompanying governance structure... Models run for specific experiments (and hence specific boundary conditions, e.g. CO2 projections) with specific output variables, frequencies, and durations run on specific platforms

23

24 (Yes we know we shouldn't have this sort of detail in the UML, and it wont be shortly) Aerosol, Atmosphere, Atmospheric Chemistry, Land Ice, Land Surface, Ocean Biogeochem, Ocean, Sea Ice

25 Scientific Properties: Controlled Vocabularies developed with expert community using mindmaps and some rules to aid machine post processing (everyone can use mindmaps: no a priori semantic technology knowledge required.)

26 A piece of the mindmap XML

27 vocabulary driven content in web based human entry tool (A great advertisement for Python and Django)

28 CMIP5 CMIP5: Fifth Coupled Model Intercomparison Project Global community activity under the auspices of the World Meteorological Organisation (WMO) via the World Climate Research Programme (WCRP) Aim: to address outstanding scientific questions that arose as part of the AR4 process, improve understanding of climate, and to provide estimates of future climate change that will be useful to those considering its possible consequences. Method: standard set of model simulations in order to: evaluate how realistic the models are in simulating the recent past, provide projections of future climate change on two time scales, near term (out to about 2035) and long term (out to 2100 and beyond), and understand some of the factors responsible for differences in model projections, including quantifying some key feedbacks such as those involving clouds and the carbon cycle

29 Introduction to CMIP5: The Experiments (two more families) Take home points here: Many distinct experiments, with very different characteristics, which influence the configuration of the models, (what they can do, and how they should be interpreted). >5500 yrs (from Karl Taylor) 29

30 Simple View of CMIP5 Projections/simulations Perturbation examples Centennial & Longer e.g. Pre-industrial control, historical, RCPs, Paleo Natural forcings only, GHG forcings only, abrupt 4xCO2 runs. Longer integrations Decadal 10 and 30 year hindcasts and predictions Hindcasts without volcanoes Atmosphere only AMIP aqua-planet

31 CMIP5 in numbers Simulations: ~90,000 years ~60 experiments ~20 modelling centres (from around the world) using ~30 major(*) model configurations ~1-2 million output atomic datasets ~10's of petabytes of output ~2 petabytes of CMIP5 requested output ~1 petabyte of CMIP5 replicated output Which will be replicated at a number of sites (including ours), to start arriving in the next few weeks. Of the replicants: ~ 220 TB decadal ~ 540 TB long term ~ 220 TB atmos-only ~80 TB of 3hourly data ~215 TB of ocean 3d monthly data! ~250 TB for the cloud feedbacks! ~10 TB of land-biochemistry (from the long term experiments alone). Download Time? ~ 45 TB ocean 3d fields for decadal experiments: 2d (10 Gbit link to yourself), 2 weeks (1 Gbit link to yourself)

32 Handling the data! Earth System Grid (ESG) Earth System Grid FEDERATION (ESGF) US Department of Energy funded project to support the delivery of CMIP5 data to the community. Consists of distributed data node software (to publish data) Tools (Live Access Server, LAS, Bulk Data Mover, BDM, security systems etc) gateway software (to provide catalog and services) Major technical challenge Global initiative to deploy the ESG (and other) software to support: timely access to the data minimum international movement of the data long term access to significant versions of the CMIP5 data. Major social challenge as well as technical challenge 32

33 Earth System Grid Data Nodes Access Control Thredds Data Server Toolbox: GridFTP ESG Publisher inc CDAT Live Access Server (other) OpenDAP servers Bulk Data Mover (BDM) Databases: Thredds Catalog, Postgres & Myproxy Filesystem: preferably with a DRS layout Deployed by data providers to expose their data via Earth System Grid Gateways 33

34 Metadata Harvest ESGF ESGF Starts with Data Nodes 20 to 30, globally distributed, each with o( )tb 34

35 Metadata Harvest ESGF ESGF Data Nodes With Data Gateways Replication Data nodes publish to Gateways Gateways replicate metadata (all data visible on all gateways) 35

36 Metadata Harvest ESGF: Nodes (Original and Replicates) & Gateways Data Replication Data replicated to Core Archives VO Sandpit, November

37 CMIP5: Handling the metadata Three streams of provenance metadata: A) archive metadata B) browse metadata C) character metadata B: Browse Metadata, added independently of the archive Exploiting Metafor controlled vocabularies via a customised CMIP5 questionnaire. compliance enforced by CMIP5 quality control systems, leading to A: Archive Metadata: three levels of C: Character Metadata information from the file system: Data assessment I. CF compliance in the NetCDF files II. Extra CMIP5 required attributes including a unique identifier within each file. III. Use of the Directory Reference Syntax (DRS) to help maintain version information. Compliance enforced by ESG publisher. Three concepts to follow up on: 1) Metafor questionnaire 2) CMIP5 quality control 3) Combining the streams (the information pipeline to the Earth System Grid Gateways) 37

38 B: Metafor Questionnaire 38

39 Metafor questionnaire: many parts... 39

40 C: Metafor Quality Control Specialises ISO19115 DQ package describes quality for CIM_Quality Record 0..n Remote Resource (identified by URL and internal URI Extrinsic! Not intrinsic! 0..n against CIM_Issues CIM_Reports CIM_Measures 0..n Log Files etc Maps nicely onto the upcoming Open Annotation Model ( 40

41 CMIP5 qctool (courtesy of Metafor) (Another great advertisement for Python and Django) 41

42 Bringing it all together for CMIP5 The players: 1) NetCDF CF Conventions + CMIP5 extensions (orange) 2) Earth System Grid + Earth System Curator (green) 3) Metafor (yellow) Conversion code (light blue/grey) Glue: Atom 42

43 Earth System Grid Gateways Earth system grid data nodes publish to a gateway (essentially the gateway harvests the information in their TDS catalog) and provide a search interface both to the harvested data, and to metadata harvested from the metafor questionnaire NCAR PCMDI 43

44 ESG Gateways 44

45 45

46 46

47 Access Control and Delivery: (1) Via Gateway Wget scripts access secure data using myproxy and X509 certficates 47

48 Access Control and Delivery: (2) Direct from Data Node Also walk the directory tree via PyDAP at BADC 48

49 Access Control and Delivery: (2) Direct from Data Node 1 49

50 Access Control and Delivery: (2) Direct from Data Node

51 Access Control and Delivery: (2) Direct from Data Node ESG (and CEDA) have comprehensive access control middleware suitable for use in browsers and command line federated globally! 51

52 Data also available via normal BADC HadGEM2-ES/ rcp45/3hr/atmos/3hr/r1i1p1/latest

53 Access through NetCDF The archive can be accessed directly from applications using the latest beta release of the NetCDF library (4.1.2 beta2, coming soon). Users will need to register, download a security certificate, compile software with the new library further details will be made available shortly. Plot by Roland Schweitzer (NOAA) demonstrating direct access to BADC archive test data node (CMIP3 data from a FERRET program running on his machine).

54 The pieces of CMIP5 support HARDWARE SOFTWARE COLLABORATION METADATA DEVELOPMENTS USAGE TOOLKITS Data storage International effort Approx. 1,000TB International effort Sub-setting Replication system Faster network Batch processing QC & Versioning systems Describing models, experiments and datasets Servers to deliver and process data MOHC DATA SUPPORT Data handling of MOHC models Checking and QC Connection to tools Interfaces to data Standard format and description for all NERC DATA SUPPORT INTERNATIONAL DATA SUPPORT Harmonisation Data handling of HIGEM and Paleo models Data handling of models Format conversion Connection to tools Checking and QC Checking and QC Connection to tools Re-gridding Format conversion Visualisation Analysis Platform UK Community Engagement with Impacts Community Public Sector, general public and Private Sector access Development of Derived Products (From a BADC perspective). Not just about storage!

55 Status summary, 20/01/2011 MOHC data available from BADC Now Data from other modelling centres Mid-February Login facilities at BADC Now ESA datasets prepared for validation Scoping Data processing by BADC Scoping Enhanced meta-data describing model configurations Data entry in progress, portal view: weeks to months. Quality control In progress. Access to data via NetCDF library Coming soon NASA datasets for validation In preparation Issuing DOIs (for accurate data citation) Later this year

56 Moving forward The Earth System Grid is a U.S. Project. There will undoubtedly be successor projects (Key role of ESG Curator and the NOAA Global Interoperability Project) The Earth System Grid Federation is a global activity, led by the Global Organisation for Earth System Science Portals (GO-ESSP) In Europe, we are underpinning ESGF via two EC funded projects: Metafor (which we have seen a lot of), and IS-ENES (InfraStructure for a European Network for Earth Simulation) (and much national work too of course) Metafor and IS-ENES are working on complementary information architectures Metafor will finish in 2011, IS-ENS has some years to run. (Metafor will leave an international governance system in place for the Common Information Model) ExArch: G8 funded proposal (awarded, waiting on EPSRC...) 56

57 And now a segue from data modelling and systems for hpc data to producing hpc data via modelling!

58 Computing Futures Top 500 #1 Best available UK climate sys Bottom climate sys (~ tier 2)

59 HPC Futures: 10 Years Expect the first exascale systems before 2020 (2015/16 according to IBM - available for tier1 in roughly 2022, and tier2 in Similarly, petascale systems will be (in principle) available for climate from next year, but more practically from around By 2022, petascale machines will be deployable in departments, and certainly accessible to the NERC HPC community. Today's HPC performance will be near the desktop Condor pools (or equivalent) will be the bane of data management... BOINC class activity will likely remain equivalent to one big machine, but data-wise network links will constrain them from being a data issue.

60 Three Questions: (1) Can we (climate) effectively (or otherwise) use that HPC? The answer might depend on (2) How would we want to use it (science-wise)? And it might depend on (3) What infrastructure needs to be in place to utilise it? Do we have it? That depends on the science choices but in general, NO!

61 Infrastructure: A hardware and software ecosystem!

62 Kiviat Diagram for Climate Science

63 Scientific Goals? European strategy for climate likely to emphasize: Predictability (and limits therein) Sensitivity and Uncertainty Reliability (at the regional level) Validation Attribution of observed signals in the instrumental record? Reproduction (and understanding) of glacialinterglacial cycles? These push the computational requirements in different directions (sometimes but not always simultaneously): Effect of resolution, processing understanding. Ensemble size Complexity and resolution Data assimilation, Processes (such as volcanism) Carbon cycle, slow earth processes, long duration.

64 But not all computations are the same. Longer execution times, more memory Coupling: more nodes or longer execution time Longer execution times, more memory (more nodes, or more memory per node & need better science) Duration Coupling and Data Handling More Computers and/or Nodes They all involve handlng more data, and all but duration require more code!

65 Realistic Progress via Punctuated Equilibrium? Thus far it has taken roughly five years for evey doubling of climate model resolution, so this would be a pretty aggressive speed of improvement, but recent emphasis on complexity is likely to replaced by an emphasis on resolution for a while...

66 John Shalf, LBNL: May 2010 BUT: Accessed 24/01/2011

67 Capacity Computing in +10 Plenty of computing available: but what sort? What we can't exploit right now Memory per node! Time to fill memory! Timescale Current Peak Flop/s 20 Peta P 1 Exa Memory 1 PB 5PB PB (*) Node Flop/s 200 G 400G 1-10 T Node Memory BW 40 GB/s 100 GB/s GB/s Node Concurrency 32 o(100) o(1000) Interconnect BS 10 GB/s 25 GB/s 50 GB/s # Nodes 100, ,000 o(million) Total Concurrency 3 million 50 Million o(billion) Total I/O 2 TB/s 10 TB/s 20 TB/s Power ~10 MW ~10 MW ~30 MW (*) MTTI (Interuptions) Days Days O(1 day) Storage 30 PB 150 PB 300 PB Source: with (*) modifications from

68 Software Progress Status Some views of community readiness According to Ken Batcher, "A supercomputer is a device for turning compute-bound problems into I/O-bound problems." Scalable Code, Network Infrastructure, Application Environments, & Parallel Libraries Will appear with little lead time! More computing? Different computing? Bigger ensembles! No problem! which is a little unfair, but I think it is fair to say that the community underestimates the effort ahead!

69 New Dynamic Cores Not Enough! NERC and Met Office: NGWCP Five Years NERC funding of 4.4M ~ 8 FTE x 4 years? Oceans and Atmospheres! New Algorithms Needed Massive Parallelisation Replace Dynamic Core Initialisation (Assimilation) Evaluation (EO etc) Framework and Coupling? My Take: Necessary activity: catch us (UK) up in scalability to international peers. Compromise activity: most scalable algorithms are not necessarily the best algorithims Will get us to front edge of current petascale (to exploit what is available NOW!) but not to exploit what could be departmental scale petascale in ten years! (50 million concurrency) So not sufficient!

70 Programming Models and Frameworks Consider completely new However, whatever the programming programming models? model, the framework has to be e.g: Instead of splitting model smarter: domain onto specific More dynamic behaviour decomposition. Queue work (including in-run decomposition items into a processor queue. onto processors as adaptive grids and/or solvers get more New algorithms needed for iterative). global sums etc. Handle checkpointing cleverly! Hide more of the metal from the Would be rather fun to find out science (which is going to be whether one could do that with a hard to do). multi-million way parallelisation of a shallow water equation model! European framework and I/O layer, with national assemblies of model components?

71 More sub-models: More I/O, More Evaluation More Archive Data could scale faster than CPU! and what about data: More sub-models: More I/O, More Evaluation More Archive Data could scale faster than CPU! Data scales with CPU (unless I/O frequency changes.) I/O and data DON'T scale With CPU (some of which is spent on timestep) I/O and archive scale with CPU (ensemble statistics alone probably not enough.) Data complexity Problems + I/O and archive!

72 The Capacity Data Future CMIP CMIP A CMIP B CMIP Atmos Resolution 1 degree 0.5 degree 25 km 10km Atmos Gridpoints 360x x x x , , ,000 5,062, Atmos % Extra Variables Storage (GB/model-mon) Storage Ratio to Comp Ratio to 2012 (data alone) Comp Ratio to 2012 (inc CFL timestep) Atmos # Gridpoints Atmos # Vert Levels 1 PB 500 x? PB Archive Size From a data point of view: increased resolution may be less of a problem than more science & bigger ensembles plus wide availability of petascale computing.? likely to be significantly > 2 Exascale Data Still a HARD HPC problem

73 The Capability Data Future Not planning for this as a data sharing activity yet! John Shalf, LBNL: May Accessed 24/01/2011

74 We can produce it, and we can store it but can we move it? Moore's Law: CPU power doubles every 18 months Gilder's Law: the total communication bandwidth triples every twelve months (doubling time about 8 months). Experience of RAL Wide Area Network (WAN) is consistent with Gilder's Law, with doubling time a little over 7 months over the last 15 years. Sounds good, but Nielsen's Law: internet bandwith doubles every months. High performance network cards have moved from 1 Gbit/s to 10 Gbit/s in a decade: Local Area Network (LAN) access performance doubling every 21 months. In 1998, the BADC moved to Token Ring (100 Mb/s) to cope with ECMWF data rates In 2010, BADC is seriously trying to exploit 10 Gbit/s cards to cope with CMIP5 data replication and delivery but fighting with the WAN headline speed is not easily achievable. Internationally (and for the Met Office) we still exploit sneakernet (sending personal RAID systems and USB disks via courier). Very staff time intensive, would prefer to use WAN! In 2022 we can expect WAN performance to cope with massive distribution, but LAN limiting massive I/O at any particular location unless we take action!

75 Real networks and CMIP5 CMIP5 Notes Volume Net: 0.4 Gbit/s Net: 3 Gbit/s (1) 100 year atomic dataset of daily data for a one-degree grid with ten levels. 100x365x360x18 0x10x4 (bytes) 500M 10s 2s (2) 6 Hourly Version of (1) 2 GB 40s 7s (3) 20 Model Aggregation of (1) 10 GB 4 min 30s (4) 10 Variables of (3) 100 GB 30 min 6 min (5) 10 Users doing (4) 1 TB 5 Hr 1 Hr (6) Ocean 3D fields from decadal experiments (most folks doing decadal prediction?) 45 TB o(2) weeks o(2) days (7) the CFMIP atmos only fields (cloud forecasting community?) 125 TB o(1) month o(5) days (8) One RAID server (worst case single data loss?) 140 TB 5-6 weeks o(1) week (9) Entire Archive Rebuild archive? 1 PB 8 months 1 month We can probably support ONE 10 Gbit/s user and up to TEN 1 Gbit/s Users

76 Practicalities of Data Volumes CMIP CMIP6 2017A CMIP6 2017B CMIP degree 0.5 degree 25 km 10km 1 Gbit/s ,289 17, Gbit/s , Gbit/s Atmos Resolution Download times (hours) for 10 years of (all) data from one ensemble member! Clearly users won't be downloading ALL data from ensembles, now or in the future! ExArch Data comparison: must avoid N x N data movements between N data production sites! Prefer N movements to M (<N) processing sites, exploit better algorithms! Data Movement might be practical MxN times, but only with lightpaths in place ( lightpath = dedicate network slice over dark fibre, provides guaranteed bandwidth unlike shared network). Want dynamic lightpaths: drop when not in use.

77 Modelling Post-Processing Infrastructure: UK Plan? &3?G Local Analysis Cloud (Users control the software environment but can mount high performance disk WITH DATA ALREADY THERE) Why light paths? For CMIP5, synchronising 1 PB archive at 1 % level implies 10 TB/day movement implies 1 Gbit/s requirement. International Light Paths will cost money!

78 Our Exascale Future SI prefix k kilo Name Power of 10 or 2 Status thousand Count on fingers M mega million Trivial G giga billion Small T tera trillion Real P peta quadrillion Challenging 103 E exa quintillion Z zetta sextillion Y yotta septillion Aspirational Wacko Science fiction 2 2 Stuart Feldman, Google, 2010 Too easy to say! (bnl)

79 e-infrastructure for Climate: a roadmap TODAY: Models developed independently and integrated (sometimes) in parochial frameworks with various level of support for their usage communities. Data held in local archives (sometimes nationally), with IS-ENES working on distributed database concepts, but poor distributed access. Difficulties with network bandwidth abound. IN TEN YEARS: Models developed by communities working with common coding conventions and shared support. Data held in distributed archives, with key data sets aggregated and replicated as necessary, with well understood routes for moving data as necessary & cloud-like processing facilities. Good and improving support for CF-netcdf in the modelling community + immature model descriptions from Metafor & Observations and Measurements standards starting to be examined by the community. CF continues to be supported, but now prevalent in the EO and observational communities. The information and vocabularies built by Metafor are maintained by an international community. O&M in wide use. Data manipulation and access tools developed independently and with various levels of support. Data manipulation and access tools are developed by communities working with common conventions and shared support.