Overview Global Operational Oceanography Systems

Eric Dombrowsky

Abstract Several systems to compute routinely ocean forecasts have been developed within the Global Ocean Data Assimilation Experiment (GODAE). They are used to deliver operational services. The cornerstones of these systems are: (1) input high quality observations obtained from space and in situ, available shortly after the measurement is done, (2) state-of-the-art realistic numerical model configurations, and (3) efficient assimilation system that combine the observations and the model physics. To be operated routinely, these components have to be integrated into a whole system that will enable routine operations, and service delivery in real-time. We present here these functions, highlighting their specific characteristics.

16.1 Introduction

Operational Oceanography (hereafter called OO) is a concept that has been largely pushed forward by the GODAE (Smith and Lefebvre 1997). Operational is a term widely used in different communities, but the meaning of it, and the understanding of its meaning vary significantly among the communities. This is why a precise definition of it has been given by GODAE to avoid confusion and diverse interpretation. Following the GODAE Stategic Plan (IGST 2000), Operational is "whenever the processing is done in a routine and regular way, with a pre-determined systematic approach and constant monitoring of performance".

Following this definition, two important ingredients are needed: (1) the production has to be regular and systematic, and the service schedule has to be pre-de-termined so that the users know precisely which services they will get, when and how, and (2) the performances, either scientific (product quality) or technical are constantly monitored to ensure the quality of the service.

E. Dombrowsky (H)

Mercator Océan, Parc Technologique du Canal, 8-10 Rue Hermes, 31520 Ramonville Saint Agne, France e-mail: [email protected]

A. Schiller, G. B. Brassington (eds.), Operational Oceanography in the 21st Century, 397

DOI 10.1007/978-94-007-0332-2_16, © Springer Science+Business Media B.V. 2011

Fig. 16.1 The three pillars of operational oceanography real-time systems: (1) space observations, (2) in .situ measurements, and (3) ocean circulation models coupled with data assimilation systems to provide ocean forecast services

The real-time OO systems are based on 3 pillars as illustrated in Fig. 16.1: (1) remote sensing observing systems, (2) in situ observing system, and (3) assimilative ocean general circulation models (OGCMs) to combine these observation and issue a forecast from which services are delivered to users.

This paper will concentrate on the systems developed to deliver real-time OO services including forecast for the ocean physics only. Biogeochemical services and reanalysis will not be considered in this paper. After this brief introduction, Sect. 16.2 presents a brief overview of the GODAE operational oceanography systems. Section 16.3 presents the key functional elements of operational systems which transform input data into services delivered to the users, through a processing chain. This list of key elements and their characteristics came out of the analysis of the existing systems developed within GODAE. Section 16.4 then presents and discusses some important non functional aspects of OO systems.

16.2 Overview of GODAE OceanView Operational Oceanography Systems

Several OO systems have been developed in the last decade. A detailed presentation of various aspects of these systems can be found in the papers published in the special issue of oceanography magazine, Vol.22-N0.3-Sept 2009, dedicated to GODAE.

In particular, Dombrowsky et al. 2009 gives an overview of the GODAE realtime systems status as of 2008. Table 16.1 below gives an update as of March 2010

Table 16.1 The main characteristics of the 13 GODAE real-time systems as of January 2010: BLUElink> (Australia), C-NOOFS (Canada), ECCO-JPL (US), FOAM (UK), HYCOM/NCODA (US), MERCATOR (France), MFS (Italy), MOVE/MRI (Japan), NCOM and NLOM (US), NMEFC (China), RTOFS (US) and TOPAZ (Norway). First column gives the name of these systems (alphabetic order), second column the name of the OGCM used, column 3 the coverage, either global and/or regional, column 4 the horizontal resolution of the OGCM configurations used, column 5 the main characteristics of the vertical resolution (type, number of levels/layers), and last column the type of data assimilation system used. We have enhanced in red the systems that have global coverage and in blue the systems that have eddy resolving capabilities (threshold 1/10°). One can denote that we have now 3 systems providing eddy resolving forecast services for the global ocean

Table 16.1 The main characteristics of the 13 GODAE real-time systems as of January 2010: BLUElink> (Australia), C-NOOFS (Canada), ECCO-JPL (US), FOAM (UK), HYCOM/NCODA (US), MERCATOR (France), MFS (Italy), MOVE/MRI (Japan), NCOM and NLOM (US), NMEFC (China), RTOFS (US) and TOPAZ (Norway). First column gives the name of these systems (alphabetic order), second column the name of the OGCM used, column 3 the coverage, either global and/or regional, column 4 the horizontal resolution of the OGCM configurations used, column 5 the main characteristics of the vertical resolution (type, number of levels/layers), and last column the type of data assimilation system used. We have enhanced in red the systems that have global coverage and in blue the systems that have eddy resolving capabilities (threshold 1/10°). One can denote that we have now 3 systems providing eddy resolving forecast services for the global ocean










47 z-levels

Ensemble OI





Can. Atl.


50 z-levels





1° x 0.3°

46 z-levels


Filter + Smoother





50 z-levels

Analysis correction


1/12 R





32 Hybrid

Multivariate OI





1/4° + 1/12°G

50 z-levels

SEEK Filter







71 z-levels






50 z-levels



1/2° + 1/10°R





42 hybrid

2D-OI + 3D-VAR





6 + 1 layers




Tr. Pac.

2° x 1°

14 z-levels




N. Atl.

4-18 km

26 hybrid




N. Atl. + Arctic

11-16 km

22 hybrid

EnKF 100 members

of the main characteristics of the systems presented in this paper and whose development continues within the initiative following on the work done by the International GODAE Steering Team (IGST): GODAE OceanView (Le Traon et al. 2010).

We see in this table that there are 13 systems operated by the OceanView partners providing forecast services in real-time, in several countries around the world:

• In the USA, there are several systems operated by several agencies:

- ECCO operated at JPL,

- HYCOM/NCODA, NCOM and NLOM systems operated by the US Navy at NAVOCEANO,

- RTOFS system operated at NOAA,

• In Europe with several systems operated in different countries:

- FOAM operated by the Metoffice in UK

- MERCATOR operated by Mercator Océan in France

- MFS operated by INGV in Italy

- TOPAZ operated by NERSC and Met.no in Norway

• In Australia with BLUElink > operated by the Bureau of Meteorology

• In Canada with C-NOOFs operated by Fisheries and Oceans Canada (DFO)

• In China with the NMEFC system operated by the National Marine Environmental Forecasting Center (NMEFC)

• In Japan with MOVE/MRI operated by the Japanese Met. Agency (JMA).

The reader can refer to Dombrowsky et al. 2009 paper to find more details and reference to the modeling and assimilation tools used.

Only a few systems have developed global eddy resolving capacity, such as the US-Navy and Mercator Océan who operate the eddy resolving global systems. This is mainly due to computer resources limitation (discussed below). In order to reach the eddy resolving horizontal resolution, several centres have developed and operate regional high resolution configurations in their region of interest, which are embedded in larger scale configurations. For example, MOVE/MRI has implemented a full suite of systems downscaling from a global configuration with 1° horizontal resolution to a North Pacific, then to a 1/10° in their local region of interest, i.e. the Kuroshio region.

In the USA, NOAA and the Navy are now concentrating on the development of common tools based on HYCOM configurations, which will progressively replace the existing systems (e.g. NLOM and NCOM).

In Europe, within GMES (Global Monitoring for Environment and Security European initiative, see Ryder 2007), the OceanView partners (associated with other non-OceanView partners), are currently developing an integrated capacity to provide marine core services to users. These developments occur within the MyOcean (Bahurel et al 2010) 3-year project which is funded by the European Commission. MyOcean was kicked off early in 2009 and aims at building on the existing assets, including those of GODAE, the bases of such marine core services in Europe.

In addition to this existing capacity, other countries are already operating, or have planned projects to implement such systems, among which are Brazil and India. They are not listed here because even if they may join OceanView soon, they are not yet part of it. One of the goals of OceanView is to include these emerging operational oceanography players as soon as their case is made. The minimum requirements to be part of OceanView are (1) a multi-year national support to operational oceanography development within the country with a strong scientific base, and (2) willingness to join OceanView.

16.3 The Key Functions of OO Systems 16.3.1 Observations, Model and Data Assimilation Quality Input Data in Near Real-Time

To run OO systems, one needs to have input observations and atmospheric forcing whose characteristics are: high quality and high availability in real-time.

This is one of the most outstanding challenges of OO, because without these inputs, it is impossible to expect any performances (such as predictive skill) of OO systems.

Ocean observations are used for mainly two purposes:

• for their assimilation, to maintain the system simulated ocean state as close as possible to the real ocean state as it is observed,

• for validation of the products.

The observations considered in the existing OO systems are:

• remote sensing: e.g. surface elevation, surface temperature, ocean color, ice concentration and drift.

• in situ: e.g. profiles of temperature and salinity from ARGO profilers, XBTs, CTDs, drifting buoys, moored stations.

For these observations, there is a need to get data that are quality controlled (QC), processed as soon as possible after the measurement is done with state-of-the-art algorithms to have a quality comparable to the one that could be obtained in delayed mode, and disseminated without delay to the OO centres.

Dedicated processing centres have been setup to handle these observations during GODAE for most of the observations listed above. This is the result of strong international organisation and effort that need to be pursued on the long run.

The data used are generally point measurements. Some systems use also grid-ded products. This is the case for instance when the assimilation system used is not advanced enough to handle point measurements. In that case, off-line gridding procedures are considered useful. However, the goal is to develop observation operators that allow handling data that are as close as possible to the measurements, in order to take into account most of the space/time information contained in the observations.

Observations are sometimes bad, for example when there is a problem with the sensor itself, or the real-time processing. In that case, the data must be rejected by the QC procedure, because any bad data entering into the system can create, if not rejected, spurious features in the analysed fields, and the recovery after such bad data have been incorporated may last for a long before its influence vanishes, an may eventually never be fully achieved.

On the other hand, as many good data as possible have to enter into the system, because the observations are crucial for system performance, and they are too sparse (the ocean and its variability are largely under sampled with the existing observing systems). Any loss of data is detrimental for the service quality (almost no redundancy in the observation systems). This is one of the major challenges OO has to face: reject all bad data, but reject as few as possible good data. This is the role of input data QC, as described in Cummings 2010 (reference in this book).

While some GODAE centres have developed their own capacity for observation acquisition and processing, such as the Altimeter Data Fusion Center (ADFC) for the altimeter data for US-navy systems, some others are relying on dedicated centres that deal specifically with these observation issues, such as the Physical Oceanography Distributed Active Archive Center (PO.DAAC) or the Data Unifica tion and Altimeter Combination System (DUACS) for the altimeters, CORIOLIS for the in situ observations, or the Global High Resolution Sea Surface Temperature (GHRSST) for the dissemination of sea surface temperature observations.

As far as real-time flow of observations to OO centres is concerned, there is still room for improvement reducing further the delay between measurement time and availability of observations for their assimilation, which ranges today from several hours to a few days, depending on the observation types. Forcing Fields

In addition to observations, atmospheric forcing fields are required for the near past, present and future (forecast). They come from outputs of Numerical Weather Prediction (NWP) services, as atmospheric variables in the upper atmosphere that are used to interactively compute (BULK formulae) the heat, momentum and/or freshwater fluxes, or directly as estimates of these fluxes. In the latter case, theses estimations made by NWP services takes into account generally a steady ocean which differs from the real one, and from the one simulated by the OO system. This may create spurious effects such as accumulation of biases in the upper ocean (no retro-action of the ocean on the atmosphere for uncoupled systems).

For the near past, remote sensing data can be also used to compute the forcing terms, among which are the wind and surface temperature satellite observations.

For more details about the input data, see Ravichandran 2010; Le Traon 2010 and Josey 2010 (references in this book)

There are several options to use the atmospheric forcing among which are:

• include or not the high frequencies (analytical daily cycle, use of hourly, 3-hour-ly, 6-hourly or daily fields),

• merge forcing with observations for the hindcast,

• extend the ocean forecast range beyond the Atmospheric forecast range: revert towards climatological forcing, using different approaches: e.g. Mercator Océan and US-Navy,

• use in house atmospheric model (e.g.: NOGAPS for the US-Navy systems),

• run coupled systems (e.g.: NCEP RTOFS system for the tropical cyclones).

Some OceanView OO systems are run by the met agencies themselves; they use their own NWP products. This is the case for example for the Metoffice (UK), NOAA/NCEP (USA), MRI/JMA (Japan), BoM (Australia) and EC (Canada). Some other systems rely on external NWP systems such as Mercator Océan (France), MFS (Italy), TOPAZ (Norway) using ECMWF products and NMEFC (China) using NCEP products. Model Configurations

Model configurations are needed to perform forecast, i.e. estimates of the ocean state and its evolution in the future. The target of this function is to provide forecast estimates which are better than the climatology and better than persistency (use the nowcast estimate and assume no temporal evolution to predict the future).

To be able to issue a forecast (and even a nowcast, since observations are available with some delay in real-time), an ocean numerical dynamical model is needed. In the past, some systems were developed based on simplified models (for example quasi-geostrophic ones), but nowadays, thanks to the increase of computing power and the emergence of communities developing state-of-the-art codes, all system use numerical OGCM solving the primitive equations.

One key point here is that an OGCM code should be used and developed by a large community to be suitable for OO, preferably including scientists from the academic research community. For instance, the NEMO (Nucleus for European Modelling of the Ocean) code tends to be largely adopted in Europe by OO centres, thanks to shared effort to maintain this code in the scientific and operational community. Similarly, HYCOM (HYbrid Coordinate Ocean Model) is now adopted by the major OO centres in the USA, benefiting from investments of a large community.

These OGCMs have several differences in their implementation, among which are the vertical coordinate systems, mixing schemes, boundary layer, turbulence closure, free surface, advection schemes. However, there is a commonality of needs:

• These codes have to be implemented in realistic configurations, which implies having good bathymetry datasets (and for the global systems, grids solving the northern pole singularity, such as tripolar grids as illustrated in Fig. 16.2)

• They have to be efficient in terms of computing and numerical schemes (e.g. implementing explicit parallelisation through Message Passing Interface (MPI), and domain decomposition techniques), because of the need to reduce elapsed time between the reference date of the last data entering the system, and the time at which the service is delivered to the user (timeliness).

The horizontal resolution of these configurations may be eddy resolving, eddy permitting or low resolution depending on both the needs and the computing capacity. It is admitted that to get the eddies resolved (eddy resolving systems), the horizontal resolution should be at least 1/10°. These configurations are either basin scale or global, depending again on the needs and the capacity of the centres. The vertical resolution is generally enhanced near the surface, with a set of O(50 layers).

Details of the model used in OO systems can be found in Barnier (2010), Chas-signet (2010), and Hurlburt (2010) (references in the same book).

Short range (a few days) synoptic forecasts are generally deterministic, with a single model run starting from the initial conditions obtained with the assimilation scheme (analysis), and forced by a synoptic atmospheric forecast. The forecast range is mostly limited by atmospheric forecast range (availability of synoptic forcing). However, forecast skill has been demonstrated for the ocean beyond the predictability scales of the atmosphere: e.g. US-Navy systems, Smedstad et al. 2003 (up to 20-30 days), reverting to climatological forcing beyond the synoptic forecast range. In addition, some studies have shown that using non deterministic atmospheric forecast can improve predictability in the ocean (Drillet et al. 2009).

Fig. 16.2 Example of grid used by Mercator and FOAM to solve the northern pole singularity. The grid is a tripolar ORCA grid (Madec and Imbard 1996). It is a classical Mercator grid up to a given latitude in the northern hemisphere. Then, it smoothly evolves toward a dipolar grid, the singularities being put on the continents. For the sake of visibility, only a sub sample of gridlines actually used is shown here. Similar tripolar grid is used for the US global HYCOM configurations

Fig. 16.2 Example of grid used by Mercator and FOAM to solve the northern pole singularity. The grid is a tripolar ORCA grid (Madec and Imbard 1996). It is a classical Mercator grid up to a given latitude in the northern hemisphere. Then, it smoothly evolves toward a dipolar grid, the singularities being put on the continents. For the sake of visibility, only a sub sample of gridlines actually used is shown here. Similar tripolar grid is used for the US global HYCOM configurations

However, most ocean short term deterministic forecast are issued using deterministic atmospheric forcing.

For longer timescales (from month to climate decadal runs), the OGCM is generally coupled with an atmospheric GCM, and eventually other earth system components models such as hydrology and ice, to ensure the interactions between all these components.

Other methods such as ensemble (statistical) forecasts which are used in the atmosphere, or the merging of several forecast produced by several systems through super ensemble techniques (Krishnamurti et al 1999) are not much developed yet in ocean forecasting centres. They will probably develop in the near future as a complement to synoptic deterministic forecast. Efficient Assimilation Techniques

In OO, the assimilation system is designed to fulfil two goals: (1) to provide the best initial conditions for the deterministic forecast, and (2) to provide the model trajectory that best fits the past observations, in order to have the best information possible about the state of the ocean in the past, eventually up to real-time. Consequently, the assimilation schemes merge the observations and the previous model forecast (also called the background state), taking into account their relative error characteristics through an analysis procedure which provide the best set of ocean variables on the model space necessary to initialize the model to run the forecast.

Note that these two objectives are not necessarily compatible, and that the best model trajectory will not necessarily provide the best initial conditions for a model forecast. The first objective applies for the operational forecasting activities, while the second relates more to the reanalysis activity.

Most analysis schemes are based on the Best Linear Unbiased Estimate (BLUE) theory such as Optimal Interpolation (OI), Kalman Filters (KF), variational algorithms (VAR) and their variants, such as the sequential smoother which take into account future observations in the analysis. These assimilation schemes are designed to compute the best set of weights to apply in a weighted average of the background state (previous forecast) and the observations, taking into account their error characteristics.

All these schemes work as a succession of forecast/analysis cycles, creating a discontinuous trajectory, with a typical saw tooth shape at the update cycle interval. To avoid the corresponding shocks to the model trajectory, the Incremental Analysis Update (IAU, see Bloom et al. 1996) has been introduced in several operational assimilation systems. It basically consists of adding small part of the increment at each time step for a given period (typically from a few hours to a few days) as a forcing term, instead of adding the full increment once at a given time step. This leads to a smooth trajectory, limiting the transients after the analysis shock. The counterpart is that this trajectory is no longer following the governing equations of the fluid, during the IAU period.

The 4D-VAR schemes are different since their goal is to get the best continuous model trajectory that fits the observations while keeping the physical balance: no statistical increment is added during model integration They consist of optimizing the trajectory changing some of the degrees of freedom of the system (such as initial conditions, atmospheric forcing, etc.), using convex optimisation (quadratic cost function minimisation). They require the usage of the adjoint model to reduce the minimisation cost (computation of the gradient of the cost function with only one forward and one backward integration of the model and its adjoint). There is currently no implementation of such a 4D-VAR method in OO forecasting centres.

For more details about the assimilation theory and practical aspects, see Zaron 2010; Brasseur 2010 and Moore 2010 (references in the same book).

There is an obvious competition between model resolution, and assimilation scheme complexity. One key aspect for OO of this function is to have a good balance between the computational cost of the model and the assimilation scheme.

For example, applying a O(100) members Ensemble Kalman Filter will multiply the model computational cost by O(100), while doubling the horizontal resolution would multiply the cost by O(10) only. Since model resolution is yet a key limiting factor in terms of forecast skill for a lot of application, most systems are based on assimilation schemes whose computational cost is the same order of magnitude as the one of the model alone. For example, the US Navy and Mercator Océan started with the development of regional high resolution models with fairly simple assimilation system, until the computer power allowed for implementation of more sophisticated assimilation methods and global models.

The TOPAZ system in Norway is within the GODAE systems an exception to this. It has been implementing an advanced (costly) assimilation scheme (Ensemble Kalman filter) since the beginning, starting with a fairly modest horizontal resolution model configurations, and increasing it following the evolution of computing power.

16.3.2 Product Generation and Quality Monitoring

Raw model products are generally files containing the ocean variables on the model computational grid. The computation grids are not necessarily adequate for most applications. They can be staggered (ARAKAWA grids), rotated, stretched, irregular, may vary with time (such as the isopycnal coordinates on the vertical in HYCOM).

Consequently, post processing of the raw model output is generally needed to create numerical products that are more convenient for the users. This function can include remapping on standard grid, tiling, averaging, applying file name and format conventions, transforming model variables into user oriented products.

This function is important to deliver the services to users. However, probably because the targeted users and the services offered are specific to each OceanView centers, there is a wide variety of implementation of this function in the OceanView systems.

We have seen above that the functions (model, assimilation) that create the raw products used to deliver services are at the leading edge of the current scientific knowledge. In addition, the quality of the product depends on the quantity and quality of the input data. These two reasons are sufficient to imply the implementation of systematic product quality control and monitoring. There are mainly two timescales to consider:

• short loop validation: there is a need to check model output and product before they are disseminated to the users,

• long loop validation: the quality of the product can vary slowly, for example, biases in the water masses can appear after several months, or seasonal biases can also develop.

The first category includes automated quality control such as comparison to predefined thresholds, and software assisted human expertise based for instance on automated graphic, indicators and metrics generation, and interactive viewing.

For example, Mercator Océan operators follow routinely a control procedure to perform routine check of the products every time the forecast is performed. These controls are based on images and diagnostics automatically generated by the system that the operators compare to templates and thresholds provided in an operational validation manual. This allows them to check if the routine production is conforming to what can be expected from the system. In order to define the reference, the scientists in charge of the system development perform a long (at least a full year, preferably a multi-year) hindcast assimilation integration with an exact copy of the real-time system. This reference hindcast simulation is used to calibrate the different validation thresholds, and to define the reference which is provided to the operators for the real-time routine validation in the operational validation manual. Then, once the system is operated routinely, it takes less than 1 h (wall clock) on average to validate all the global and regional forecast products. In case of doubt, the operators can also further investigate the quality of the products visualizing the 4-D fields with an interactive quick look viewing software (allows also to compare with the observations, the climatology, to look at the forcing fields, to zoom in regions, at depth, etc...). In the ultimate case they detect an anomaly that they cannot solve with predefined procedures, they call the specialists (scientists) to further investigate the problem in order to solve it and resume as soon as possible to normal operations.

The second category of quality control is based on regular studies, looking at regions, or specific phenomenon depending of what is happening in the real ocean, or on opportunities (for example a scientific campaign in one region). These studies can contain comparisons with other systems (as it has been done within GODAE, see Hernandez et al 2009). In any case, these quality control studies have to be as exhaustive as possible (all regions, all seasons, and all phenomenons). This is extremely costly in terms of human resources, and can only be afforded if there is a strong involvement of the users and the scientific community.

16.4 Non Functional Aspects 16.4.1 Operational Resources

Systems have to be operated on a routine base with constant and systematic monitoring of performances as stated in the Operational definition given in the introduction. This means that operational resources are necessary to ensure service continuity. This concerns the IT resources (computing, storage and network) but also the people. Staffs dedicated to these tasks are to be involved, with backups in case a person cannot go to work for various reasons. Such activity cannot be done with R&D type staff only and is not compatible with the "best effort" approach on the long run.

In addition, the best R&D system may not be suitable for operational purposes. For example, a system that give very good results most of the time, but which does not always converge will not enable to deliver continuous service.

To implement an OO system, one has to define the performance target in terms not only of product quality (scientific performance) but also in terms of service availability. Operational activities include continuous measure of the effective performances relative to the target, and measure of the progress (at least non regression) made at each system upgrades.

16.4.2 Research and Development

The gap between what we can achieve today (technology and science push) and the user's need (user pull) is still large for some applications and in order to better match the user's needs in terms of accuracy and performance, the OO systems have to be based on ingredients that are at the leading edge of the research such as state-of-the-art model and assimilation techniques as described above.

Hopefully this gap can be (and is continuously) reduced, thanks to advances made in our knowledge and tools. It can be done if there are sufficient research efforts associated to the OO development. This is why most OceanView groups have strong internal R&D effort to support their operational systems.

16.4.3 User Involvement

The OO systems are built to deliver services to users, their feedback on the service quality is very important to feed the virtuous loop of service continuous improvement. All the successful OO systems developed within GODAE have a strong user base. For instance, Navies, as supporting users, have played a major role for the development of OO during GODAE in several nations such as the US, Australia, Canada, UK and France.

However, getting this feedback has to be organised, through a real engagement of the users in the OO development.

16.4.4 High Performance Computing Facility

Running systems involving eddy resolving basin-scale model configuration with descent assimilation schemes require high performance computing facilities.

For example, the 1/12° Mercator Océan global model has 3059 * 4322 * 50 grid points, i.e. O(109) grid points. A corresponding 3D array (for one variable, e.g temperature) represents 5.3 GB in computer memory. The total memory size of the corresponding system (assimilation and model) is of the order of 1 TB.

This system is run weekly with a 2-week hindcast, with 2 analyses, it has a backward IAU (which means the model is run twice per assimilation cycle), and a 7-day forecast is then issued. It runs on 4 nodes (64 processors) of Météo-France NEC SX-9 machine. The model alone takes 1 h (wall clock) per week (time step for this non tidal model is 480 sec), each analysis takes 0.75 h (wall clock). This means a total of about 9 h (2 analysis, 35 model days and computation of diagnostics) elapsed every week to deliver the forecast.

Doubling the resolution to better match the requirements of the users for which 1/12° is barely sufficient to resolve the physics they are interested in, would mean multiply by a factor of 4 the size (memory) and a factor of 8 the need for CPU time on the same computer.

This illustrates the fact that computing resources is yet a key limiting factor to the development of global high resolution operational oceanography systems, and that high performance computing facilities are required to be able to run such systems. Hopefully the computing power increases regularly, following an empirical law, originally introduced by Moore in 1965 (known as Moore's law) which generally admits that the available computing capacity doubles every 18 month.

16.4.5 Storage, Dissemination Capacity and Service Delivery

The OO systems generate a huge amount of data that have to be physically stored to provide the services.

For example, the volume generated by Mercator Océan global 1/12° systems is 0.5 TB per week and the total volume that will be archived in 2010 by Mercator Océan corresponds to 60 TB.

Producing and archiving these data would be useless without enabling their fast and easy access to the users.

This concerns the data produced regularly in real-time as well as past data that have to be archived in order to (1) deliver services on past data (a common user request), (2) assess the performances of the system upgrades on the long run, and (3) compute climatological datasets (an other common user request).

The problem is not only a question of storage capacity, but also a question of efficient access to the data stored. This means that there is a need for efficient systems to enable the users to access directly in a timely manner to the information they require. Such big datasets cannot be delivered to anyone via simple "ftp-like" download, especially for those who don't have a strong IT capacity.

To make these data useful to users, efficient dissemination system based on (1) large live data repositories with fast access and large bandwidth internet capacity, (2) functions to help the user browse the archives (catalogue, inventory, documentation and meta-data), to preview the data, and to extract what they need (efficient sub setting, aggregating, extracting and remapping tools) need to be implemented.

Hopefully, some technologies (such as like OPeNDAP/THREDDS, and LAS, associated with big data sharing systems) exist, are efficient and they are developing rapidly following the pace of the development of the OO systems.

In addition to software tools, a human organisation has to be put in place: the Service Desk (or Help Desk) to help the user with the data, to register the requests and make sure that the service is delivered. This means that a phone number, an e-mail address, the name of the person to call has to be delivered to the users. This means also that a specific organisation, with dedicated people committed to these tasks, has to be setup at the centres which disseminate the products. This is an operational function also.

16.5 Conclusions

We have seen here that Operational Oceanography systems exist. They have been developed in several countries thanks to international coordination for the development of the ocean observing system, and thanks to coordinated actions within GO-DAE. Today, 13 systems—among which 3 are global eddy resolving systems—are routinely operated in operational centers, and provide routine high quality operational services to users.

Other systems will emerge and join this international endeavor in the near future within GODAE OceanView.

All these developments would not have been possible without the international effort to put the ocean observing system in place, including altimetry and ARGO autonomous in situ measurements, and the delivery in near real-time of high quality data from these observing systems.

All the operational system developed to deliver real-time ocean forecast services are based on state-of-the-art ocean models and assimilation techniques that are at the leading edge of the existing knowledge in these disciplines. This means that OO could not be further developed without strong R&D efforts.

Running forecast systems in an operational context implies to have a strict engineering approach to design and implement these systems. We have presented the major characteristics of the main scientific functions (e.g. model, assimilation) that are implemented currently, and more specifically the computation efficiency requirement that apply on these functions to be able to have a good trade-off between scientific performance and timeliness of the service delivery, which is very important in the OO context, probably not so important for academic research or reanalysis purposes.


Bahurel P, Adragna F, Bell MJ, Jacq F, Johannessen JA, Le Traon PY, Pinardi N, She J (2010) Ocean monitoring and forecasting core services, the European MyOcean example. Proceedings of OCEANOBS'09 conference Bloom SC, Takacs LL, DaSilva AM, Levina D (1996) Data assimilation using incremental analysis updates. Mon Wea Rev 124:1256-1271

Dombrowsky E, Bertino L, Brassington GB, Chassignet EP, Davidson F, Hurlburt HE, Kamachi M, Lee T, Martin MJ, Mei S, Tonani M (2009) GODAE systems in operation. Oceanography 22(3):80-95

Drillet Y, Garric G, Le Vaillant X, Benkiran M (2009) The dependance of medium range northern Atlantic Ocean predictability on atmospheric forecasts. J Oper Oceanogr 2(2):43-55

Hernandez F, Bertino L, Brassington G, Chassignet E, Cummings J, Davidson F, Drevillon M, Garric G, Kamachi M, Lellouche J-M, Mahdon R, Martin MJ, Ratsimandresy A, Regnier C (2009) Intercomparison studies within GODAE. Oceanography 22(3):128-143

IGST (International GODAE Steering Team) (2000) The global ocean data assimilation experiment strategic plan. GODAE report no 6, Dec 2000

Krishnamurti TN, Kishtawal CM, LaRow TE, Bachiochi DR, Zhang Z, Williford CE, Gadgil S, Surendran S (1999) Improved weather and seasonal climate forecasts from multimodel superensemble. Science 285(5433):1548-1550. doi:10.1126/science.285.5433.1548

Le Traon PY, Bell M, Dombrowsky E, Schiller A, Wilmer-Becker K (2010) GODAE OceanView: from an experiment towards a long-term Ocean Analysis and Forecasting International Program. In: Hall J, Harrison DE, Stammer D (ed) Proceedings of OceanObs'09: sustained ocean observations and information for society, vol 2, ESA Publication WPP-306, Venice, Italy, 21-25 Sept 2009

Madec G, Imbard M (1996) A global ocean mesh to overcome the North Pole singularity. Clim Dyn 12:381-388

Moore GE (1965) Cramming more components onto integrated circuits. Electron Mag 38(8):114-117

Ryder P (2007) GMES fast track marine core service, strategic implementation plan. Report from the GMES marine core service implementation group to the European commission GMES Bureau

Smedstad OM, Hurlburt HE, Metzger EJ, Rhodes RC, Shriver JF, Wallcraft AJ, Kara AB (2003) An operational eddy-resolving 1/16° global ocean nowcast/forecast system. J Mar Sys 4041:341-361

Smith N, Lefebvre M (1997) The Global Ocean Data Assimilation Experiment (GODAE). Paper presented at the Monitoring the Oceans in the 2000s: an integrated approach, Biarritz, France, 15-17 Oct 1997

Other Lecture Notes (in the same issue)

Cummings on QC,

Ravichandran, Le Traon and Josey on input data, Barnier, Chassignet and Hurlburt on models Zaron, Brasseur and Moore on data assimilation

Was this article helpful?

0 0
Guide to Alternative Fuels

Guide to Alternative Fuels

Your Alternative Fuel Solution for Saving Money, Reducing Oil Dependency, and Helping the Planet. Ethanol is an alternative to gasoline. The use of ethanol has been demonstrated to reduce greenhouse emissions slightly as compared to gasoline. Through this ebook, you are going to learn what you will need to know why choosing an alternative fuel may benefit you and your future.

Get My Free Ebook

Post a comment