Extending the NetCDF Supported Data Formats using a Dispatch Layer Dr. Dennis Heimbigner Unidata netCDF Workshop October 26, 2012

Overview Extensible netCDF Architecture Dispatch Table Selection Rules Adding a New Dispatch Table Questions

Extensible netCDF Architecture The idea is to add a layer of indirection between the client and the code that implements the API Client Program nc_open() … nc_get_var() nc_close() netCDF API Wrapper Procedures nc_open() nc_get_var() … nc_close netCDF-4 Dispatch Table NC4_open() NC4_get_var() … NC4_close

Extensible netCDF Architecture (cont.) Actual semantics of a netCDF API call will be determined by the choice of dispatch table Currently support: netCDF-3 (classic) netCDF-4 (enhanced) DAP => netCDF-3 CDM-Remote => netcdf-4 Proposed additions: EOS, DAP4 Allow for user-community defined extensions Note that HDF-5 is currently implementing something similar.

Dispatch Table Selection Rules Key problem: when the client calls nc_open() or nc_create(), which dispatch table do we use? The decision can be based on the following pieces of information: Path – file path, url, or something else URL markers – e.g. <url>#cdmremote Mode argument – a specific flag (e.g. NC_NETCDF4) Contents of existing file (when using nc_open) NC_set_dispatch_override() – to force a choice Environment variables (not currently used) .rc file (not currently used)

Adding a New Dispatch Table Briefly, the steps are as follows. Build a library that implements the netcdf-3 or netcdf-4 API in terms of your Data format Implement a dispatch table that maps the netcdf API to the equivalents in your library All dispatch table entries must be supported, even if only to return an error. Modify the nc_create and nc_open wrappers to determine when to use your dispatch table

Questions?

Dispatch Architecture Path Mode flags Path Markers Existing File (open) Client Program nc_open() … nc_get_var() nc_close() netCDF API Wrapper Procedures nc_open() nc_get_var() … nc_close Dispatch Table For e.g. Netcdf-4