Intercomparison exercise
 
 
Welcome
Project information
Overview of the models
The intercomparison framework
Setting up the integrated system
Access to Ocean Data
Working area (secured)

The Intercomparison Framework

North Atlantic Ocean - Mediterranean Sea - North Pacific - Sea Ice


The ocean forecasting systems differ in many way. In order for all teams to meet on common issues and problematics, they need to agree on a common well defined framework, which covers three separate issues:

The Intercomparison framework for the North Atlantic ocean (NAT) and the Mediterranean sea (MED)


  • Metrics

    The definition of metrics is aiming at such a goal. Metrics means definition of common quantities and diagnostics with a given mathematical definitions. The internal metrics has been defined in the following document:

    Metrics definition for the North Atlantic ocean and Mediterranean sea

    C. Le Provost et al., 2004
    (version 5, 3 may 2004, Mersea strand-1 - WP4 intercomparison project)
    (.doc.zip, 1002 Kb)

    Because not all the systems cover the same region, 2 areas of interest are considered with common coordinates and grid for each model:

    • Mediterranean Sea (MED)

      Coast to coast
      Unique standard 3-d grid: 1/8° in horizontal, 8 predefined standard depth levels (MEDATLAS)
    		(FOAM, MERCATOR, MFS)

    • North Atlantic (NAT)

      From 10°N to 68°N
      Unique standard 3-d grid: 1/8° in horizontal, 12 predefined standard depth levels (LEVITUS)
    		(FOAM, HYCOM, MERCATOR, TOPAZ)

    Metrics defined for the North Atlantic and the Mediterranean basin are sorted into 4 classes (class1, class2, class3 and class4) and their definition can be summarized as follows:


    Class 1
     primary products, 2D and 3D gridded products, daily fields
    • 2D fields
        wind (Tx, Ty)
        total net heat fluxes including relaxation terms (Qtot)
        water flux (E-P-R) including relaxation terms
        Barotropic Stream Function (BSF)
        Mixed Layer Depth (MLD) (MLD(t°) for NAT and MED plus MLD(rho)for NAT))
        Sea Surface Height (SSH)
        Mean Dynamic Topgraphy (MDT)

    • 3D fields
        T, S, U, V

    • 3D fields
        (T,S) from Reynaud and Levitus climatology in the Atlantic and from Medatlas climatology in the Mediterranean basin

    All Class1 fields from all oceann forecasting systems and from climatologies are interpolated on the same Mersea grid with a horizontal resolution of 1/8° and vertical resolution made of 8 reduced standard depth levels for the Mediterranean and 12 reduced standard depth levels for the Atlantic - deduced from climatology -
    The bathymetry field of each model corresponds to the landmask.

    Class 2
    other 3-D model outputs, high resolution sections and moorings, daily fields
    • 3D fields
        T, S, U, V

    Interpolated along high resolution sections tracks - every 10 kilometers - and at moorings locations, and given at climatological depth levels (not reduced)

    - for NAT: 30 transport sections (straight and not), 8 XBT sections and 1D table (19 moorings), Levitus depth levels –
    - for MED: 16 transport sections (straight and not), 11 XBT sections and 1D table (8 moorings), MedAtlas depth levels –

    (access here sections name and sections definition: straight section on NAT, XBT sections on NAT, straight sections on MED, XBT sections on MED)
    NAT and MED moorings
    NAT and MED moorings
    NAT and MED moorings

    Class 3
    Integrated quantities such as daily volume transport through given sections, daily fields
    • meridional heat transport
    • overturning stream function (f(Z), f(T), f(rho)).
    Generated at the source, the model native grid.

    Class 4
    Daily Root mean square statistics to assess data assimilation methods performances

    Class 1 to 3 diagnostics are provided for the daily mean best estimates fields on a daily basis (the best estimate corresponds to the best field that each forecast system can produce), as well as for the T0+6 day forecast. Class 1, 2 and 3 are available from July 1, 2003 till June 30 2004 and the intercomparison assessment will cover the first nine months. Class 4 diagnostics final definitions have been agreed at the Bologna, Mersea Feb23-25 2004 meeting (see metrics document version5). They have been tested by Mercator and Topaz and remain to be computed by all the systems. They will not be used for the present assessment.

  • Product coherency and standardisation

    To help the intercomparison exercise, it was first requested that product be harmonised and standardised as follows:

    • Model documentation

      Each center listed and documented similarly their operational system and the distributed data (model overview, history file).

    • Convention and format issues
      • The data should be portable, self-describing.
      • Conventions should be applied; they have been developed for metadata readable by human & program.
      • Care for a higher degree of product coherency / harmonisation to greatly reduce the complexities of setting it up.

        (cf. product selection and organisation, product dissemination,
        plus discipline specific semantics layered on the data to ease exchange and joint use of interdisciplinary data.)

      Metadata provides a description of data. Precise and adequate metadata is enormously important in any project where large quantities of data have to be handled. If the data comes from a variety of sources, it is essential to adopt some standards for the metadata so that common programs can be used for analysis and comparison (i.e., variable.name coherency - standard names, short and long names -, units standardisation, table dimensions and sub-samplings, , tzyx organisation, attributes and other descriptions, product selection and organisation.

      We chose the NETCDF format (Unidata Network Common Data Form) + COARDS/CF conventions (Cooperative Ocean / Atmosphere Research Data Service (COARDS) - Climate Forecast (CF), see Conventions for the standardization of NetCDF files, NetCDF Climate and Forecast (CF) Metadata Convention, CF Conformance Requirements and Recommendations & CF standard name table). As a file format for data exchange, netCDF has plenty to recommend it: it is portable, binary, easily translatable to and from an equivalent ASCII format, and supported by a lot of freely available software for processing and graphics, including the netCDF library itself, CDAT, Ferret and NCO. The COARDS netCDF standard is widely used. It has conventions for identifying coordinate axes (longitude, latitude, vertical and time), and for specifying units and missing data values. CF is a standard for "use metadata", whose aim is to distinguish quantities (physical description, units, prior processing, etc.) and to locate the data in space-time and as a function of other independent variables (coordinates). This is the kind of metadata that is used at the time the data is processed and displayed; it can be distinguished from "discovery metadata", which is used in catalogues for identifying datasets. CF provides only rather basic discovery metadata, such as ways to record where and how the file was produced.

    Standard nameComment
    Sea water potential temperature (degC)temperature
    Sea water salinity (psu - 'Practical Salinity Units')salinity
    Eastward sea water velocity (m/s)
    Northward sea water velocity (m/s)    		zonal velocity U
    meridian velocity V
    Sea surface elevation (m)sea surface height (ssh)
    Temperature ocean mixed layer thickness (m)
    Density ocean mixed layer thickness (m)    		temperature MLD
    density MLD (MLP)
    Ocean barotropic streamfunction (m3/s)ocean barotropic streamfunction (bsfd)
    Surface downward eastward stress (Pa - Pascal)
    Surface downward northward stress (Pa - Pascal)    		windstress eastward Tx component
    windstress northward Ty component
    Surface downward heat flux in air (W/m2)Total net heat flux (Qtot)
    Water flux into ocean (Kg/m2/s)Water flux (EMP = Evaporation - Precipitation - River)
    Class 1 ocean parameters


  • Mersea information and product management system

    The Mersea strand-1 information management system

    The Mersea strand-1 information management system

    The underlying philosophy was that data should be managed independently at participating sites:

    • data at one place (local disk),
    • expose with Opendap on Internet,
    • manipulate and visualise thanks to application tools
    • plus a federating WWW product server
      based on HTML pages and Opendap/Las/Ferret established connexions

    • Data product distribution: transport via Internet

      The requirements for the data distribution was with respect to data discovery and transport, that is:

      • To distribute / transport data via Internet (push/pull integration)
        (with minimum constraint)
      • To manage large data sets, numerous data flows and numerous users
      • To allow synctatic and semantic operability
        (consistent format representation across data sets,
        consistent semantic representations of the data)
      • To preservate data and products
      • To rely on open source technology
        associated to reliable, sustainable, efficient operations

      We choose the Opendap technology (cf. http://www.opendap.org) because it has been designed to minimize the barriers to sharing data over the Internet (supports server side subsetting of data and aggregation). It provides strong support for data stored in NetCDF as well as for users of NetCDF enabled programs. The goal is to allow end users, whoever they may be, to access immediately whatever data they require in a form they can use, all while using applications they already possess and are familiar with. Opendap is a mechanism to facilitate access to data over the Internet network. Opendap client exists for many application packages (e.g. NCBrowse, Excel, Matlab, IDL, Ferret, GRADS, IDV, Las, Map Server). The data request functions use the http protocol, sending an enhanced URL to the server. Opendap also allows server-side function evaluation and advanced computational issues, as well as user traceability and user feedback (via logs analysis) for system improvements and end-users knowledge.

      Opendap has been serving the marine community since 1995 and serves already a broad range of data, including oceanographic, atmospheric, and even astronomical data (cf. the Opendap master data set list, http://www.opendap.org/data/).

      Such e-technology choice is in agreement with the IOOS Data Management And Communication plan (DMAC) and the GODAE implementation plan

      Each model team distributes their data on the Internet network via an Opendap aggregation server.



    • Product manipulation / Product visualisation

      The requirements for the data manipulation and visualisation was:

      • To convey the inter-comparison exercise i.e., allows selection (and download) of chosen fields from each system's Opendap server and plot them in a very simple and convenient way
      • To unify the access to the model outputs and hide the differences in data management (cf. file naming conventions, how long to keep files on lines, whether variables are stored as individual files or consolidated)
      • To manage large data sets, numerous data flows and numerous users
      • To rely on open source technology associated to reliable, sustainable, efficient operations

      Above the Opendap technology, we found Internet applications which allow to manipulate and visualise the data distributed by the Opendap servers:

      • direct Opendap client application tools for any MERSEA products
        (like the Opendap-Matlab command line client which has been widely used by the intercomparison exercise people to generate monthly average values and corresponding intercomparison plots - made available for all in the discussion area -. )

      • a (central federating) Live Access Server (LAS) for class 1 model output products (which is an interoperable mapping tool and which unify the access regardless of the differences of individual Opendap servers) (cf. http://ferret.pmel.noaa.gov/Ferret/LAS/).

        The Live Access Server unifies the access to the model outputs regardless of differences of individual Opendap servers. Las is a configurable, interactive and inter-operable scientific data "product" server, a on request - on the fly mapping tool A user can quickly obtain products such as plots, images, and formatted files, generated on-the-fly, from custom subsets of variables - any t, z,y, x combination -

        Las has a comparison mode which allows the user to select any data sets distributed on Internet via Opendap and link to the LAS, then to compute differences (with automated regridding - refer to the official LAS web site for information on the interpolation method - ), overlay them graphically and view them as side-by-side plots (-This feature has been developed especially for GODAE -).

        Las also allows user traceability and user feedback (via logs analysis) for system improvements and end-users knowledge.

        Since implementing Opendap and Las e-technology requires configuration expertise, we didn't require to have a Las per center and a sister-Las above them for federation. But we implemented a Las connected to individual Opendap and implemented a synchronisation process (the notification).


 

 

 

Other Intercomparison frameworks for the North Pacific ocean (PAC)

The metrics defined for Mersea Strand1 fit the North Atlantic ocean and Mediterranean basin for the existing basin-wide European operational system. They can be easily extrapolated and used as an example to develop further metrics for any other operational system oriented towards bio-geochemical, coastal, polar, global, specific basin issues within the MERSEA-IP and GODAE frame. As an example, Metrics are now being defined for polar areas (metrics on ice, by G. Garric), as well as for the North Pacific ocean.