Ocean Model Analysis and Prediction System

Science and Technical Implementation Plan Workshop

26^th-27^th October 2005

Bureau of Meteorology

Summary report

Gary B. Brassington

Bureau of Meteorology Research Centre

g.brassington@bom.gov.au

7 November 2005

Introduction

BLUElink is a partnership of the Bureau of Meteorology, CSIRO and Royal Australian Navy to develop Australia’s first operational ocean forecast system. This project, officially launched in 2003, sets out a formal schedule for completing the development of the individual components and prediction system. The prediction system is scheduled for transfer to operations in December 2006. The June 2005 contract milestones marked the transition in the BLUElink contract from scientific development to implementation and scientific validation. The Scientific and Technical Implementation Plan (STIP) is being developed to provide the detailed plan of the system configuration and timetable for implementation, trial and monitoring.

The operational system throughout the trial period is referred to as the Ocean Model Analysis and Prediction System or OceanMAPS. OceanMAPS is a global ocean prediction system with enhanced resolution in Australia’s marginal seas. The system is intended to provide from 7 to 28 day forecasts making use of the NWP and climatological fluxes and near real-time observations.

The science and technical implementation plan (STIP) workshop was convened to provide an opportunity to review and refine the plan for the trial Ocean Model Analysis and Prediction System (OceanMAPS) being developed under the BLUElink contract. The STIP describes the complete system including a detailed plan for the configuration of each individual system component. The STIP covers all stages of the implementation from initial configuration through to operational certification scheduled for January 2007.

OceanMAPS is a completely new system with few useful benchmarks in the Bureau or CSIRO. The closest prototype to OceanMAPS at the Bureau is NWP with GASP and LAPS. The timescales of interest and the general structure of the system share many similarities to these systems. However we need to be mindful that the similarities diverge when it comes to the practical implementation. NWP has been established for over 20 years at the Bureau and is now a very mature system. Operational implementations are largely restricted to system upgrades, which have established pathways together with experienced staff to carry it out.

OceanMAPS design overview

The design of OceanMAPS must satisfy two goals: (a) robustness and (b) skill. Compared with NWP operational oceanography is in its infancy and the observing system can only be considered quasi-operational. In this type of environment robustness can be difficult to achieve and a sophisticated control system will be required to account for an elaborate set of contingencies. OceanMAPS has been composed of several modular systems that can be defined in terms of interfaces. These systems are shown in Fig.1 and include:

1. Operational archival management
1. Satellite data archival system
2. Profile data archival system
2. Operational retrieval management
1. ODAS data retrieval system
2. OGCM data retrieval system
3. Satellite data retrieval system
4. Profile data retrieval system
5. Surface flux retrieval system
3. Operational control systems
1. ODAS control system
2. OGCM control system
3. Delayed/symmetric analysis cycle
4. Real-time/asymmetric forecast cycle
4. Operational product management
1. Analysis product archival system
2. Ocean model product archival system
5. Data servicing management

Note the system description has made use of generic component names Ocean Data Assimilation System (ODAS) and Ocean General Circulation Model (OGCM). In the first version of OceanMAPS ODAS and OGCM will be an implementation of BODAS and OFAM respectively.

Ocean observations have the following properties: (a) the observations are sparse in time and space, (b) the observations are only semi-operational and (c) the observation quality increases significantly in time. All of these properties suggest that the near real-time analysed state could introduce biases and error that could lead to more rapid model drift. Three strategies are being considered to remove model drift:

(a) Relaxation of the deep water to climatology

(b) Compute a best estimate of the ocean state using a delayed analysis cycle to include more observations and higher quality observations

(c) Re-introduce a cold start from a climatological/spinup restart.

All three strategies may prove to be necessary at various stages of the system operation. The second strategy is being developed for trials. The best estimate of ocean state obtained from the delayed analysis is used as the starting point for launching a NRT analysis sequence. The NRT analysis is closer to real-time and will have fewer high quality observations and an asymmetric analysis window. This ocean state is used temporarily to produce an ocean forecast. A delayed analysis cycle would incur an additional cost in terms of computations and storage. This will need to be evaluated against the gain in reduced forecast innovations.

Figure 1: Schematic representation of the OceanMAPS system components and the flow of information

Figure 2: Schematic representation of the proposed analysis and forecast cycles for OceanMAPS

Proposed implementation plan

The STIP is an explicit plan for the complete implementation of the first version of OceanMAPS into operations at the Bureau of Meteorology. The STIP covers the scientific and technical aspects of the system configuration together with a schedule for the operational trial and monitoring period.

The draft STIP has been prepared as an online document and exposed on the Bureau external server at http://www.bom.gov.au/bmrc/ocean/BLUElink/OceanMAPS/. Broad contributions and participation was sort from BMRC, NMOC, HPCCC, OEB, CSIRO and the RAN. The draft STIP was made available to these groups for review and comment leading up to the workshop. Not all of the prepared documentation was available to participants due problems with the external transfer program. The complete version is available internally on the Bureau intranet at http://gale.ho.bom.gov.au/bm/internal/ocean/BLUElink/OceanMAPS/.

The first complete version is expected to be available in November with the contents as outlined in Appendix A.

Proposed implementation schedule

The implementation of the trial system will consist of three phases each of approximately 6 months duration:

Phase 1 Infrastructure: Implement the trial system configuration as defined by the STIP. The implementation is further divided into two sub-systems each of 3 months duration:

1. Symmetric re-analysis cycle
2. Forecast cycle

The conclusion of the first three-month period coincides with this workshop. The analysis cycle will be demonstrated at the workshop and the forecast cycle plan reviewed.

Phase 2 Tuning: At the conclusion of Phase 1 a complete operational configuration will be available for trials. Phase 2 will conduct and report on the trial schedule defined by the STIP. This phase is also divided into two sub-components of 3 months:

1. Robust configuration
2. Extended configuration

The robust configuration will form the backbone of the forecast system and will include only those components tested and likely to be robust. The robust configuration might include the GASP fluxes only and an “aggressive” QC system. The extended configuration will include features that are potentially less robust and need to be tested within the robust configuration. Extensions might include blended GASP/LAPS fluxes, optimised QC and symmetric and asymmetric analysis cycles.

Phase 3 Monitoring: Based on the results of the operational trials in Phase 2 the “best” configuration for operational implementation in December 2006 will be adopted. The “best” configuration of the system will be “static” and assessed for robust delivery of forecasts throughout the monitoring period.

The specific goals for the monitoring period will include: (a) Monitoring, (b) Routine diagnostics, (c) Validation and skill assessment, (d) Ocean briefings and (e) Documentation complete.

Workshop timetable

The timetable followed during the workshop is shown in Appendix B which took place over two days. The workshop was broken into 10 one hour component sessions together with an introduction and workshop summary. Each component session was started with two 15 minute presentations that highlighted scientific and technical issues for OceanMAPS implementation. This was followed by a 25 minute session for open discussion on any aspect of the component motivated by the talks or participant questions.

Workshop outcomes

OFAM

• Neutral physics has been switched off for SPINUP4 following Steve Griffies recommendation
• The impact of no neutral physics on SPINUP4 has not been assessed. CSIRO will investigate this issue
• The new time integration scheme was used in SPINUP4 and provided slightly better than a doubling in timestep
• A mixed layer tuning was tested during SPINUP4 in order to provide better agreement between OFAM and climatology
• The tuning was believed to be surface flux independent and may translate to OceanMAPS
• It is recommended that this tuning be investigated in OceanMAPS trials
• Tim Pugh analysis of OFAM suggested inefficiency in the SBC code due to MPI calls and I/O might be improved by 20%. Russell identified some specific profile I/O diagnostics that were contributing to this performance.

BODAS

• Peter Oke was absent due to illness preventing a full and robust discussion
• New ensemble anomalies and statistical datasets will be derived from SPINUP4
• The impact of smaller time windows or large observation window overlaps for OceanMAPS will need to be tested in the trials
• The impact of an asymmetric observation window of near real-time observations has not been tested in BRAN and will need to be tested in the trials
• Russell suggested an MPI implementation for CALC but Peter was not experienced in MPI programming
• Tim Pugh analysis of BODAS suggested that PREP and POST might be improved. The specific case Tim looked at did not have many observations and might bias the conclusions
• Russell Fiedler says his runs of BODAS assimilate a larger number of observations resulting in CALC dominating the computation time. He did not feel PREP and POST were significant
• In the near real-time applications the quantity of observations will be reduced from BRAN which will reduce the dominance of CALC and PREP and POST may still be an issue.

OceanMAPS

• The proposed configuration includes a behind real-time analysis cycle performed on a 24hr cycle and a near real-time forecast analysis. The design is an attempt to make maximum use of ocean observations that can take several days to arrive. The proposed configuration introduces a higher cost that must be justified by the higher forecast skill. There are several critical parameters introduced: (a) the delay used for the behind real-time analysis cycle, (b) the observation window for a 24hr cycle, (c) the observation window for the near real-time analysis and (d) how close to real-time the forecast analysis should be performed. Tuning the appropriate values will be pursued in the operational trials.
• Forecast frequency
• ROAM (Peter Craig) suggested that a daily cycle for OceanMAPS would be necessary.
• RAN (Robert Woodham) expressed his support for a daily forecast cycle
• Contract establishes a minimum service level of two 7day forecasts per week
• Daily forecasts would have potential impacts on the operational schedule and archive storage
• A full estimate of the costs for the forecast system will be provided to the executive to assess the appropriate service level
• RAN and Bureau will need to enter discussions to determine the appropriate operational service level
• GASP or GASP/LAPS
• OFAM grid was designed to make use of LAPS fluxes
• GASP only is a simpler system and recommended for the robust configuration
• RAN (Robert Woodham) expressed interest in OceanMAPS using the LAPS fluxes
• LAPS is a 3day forecast. Skill reduces rapidly over the 3 days.
• GASP/LAPS momentum fluxes are not consistent when compared with QuikSCAT
• LAPS resolution 0.375 is not significantly better than GASP 0.75
• Proposed to use a 7day forecast which provides a 3day overlap with the 10day forecast period of GASP. The 3 day overlap is aimed at providing some redundancy for GASP/LAPS failures. A recent incident demonstrated that GASP can be delayed by the objective analyses rather than a broad system failure
• No interest was expressed in the proposed 28day forecast cycle
• The “best” fluxes to use for a 28 day forecast unknown. Climatology, diurnal cycle. Does GASP have a climatology?

Servicing

• AIFS has been on hold for 12 months. Critical activity on the replacement system has made only modest progress.
• It is desirable to develop operational products for OceanMAPS throughout the trial period. Delays in the servicing infrastructure will force interim solutions to be used and duplication of effort
• RAN/ROAM expressed an interest in a daily forecast product. Determining the initial service level is a critical activity for the Bureau’s executive
• A mock set of OceanMAPS output in the defined netCDF format will be prepared for ROAM to undertake operational configuration trials
• The basic public product set for OceanMAPS is yet to be defined
• BRAN forms the best prototype for the initial product development
• Development of the basic product set will require greater engagement with the potential user community for OceanMAPS. Developing a broad user community will be critical to justifying the resources required by OceanMAPS

High performance infrastructure

• OFAM currently uses 42 dedicated processes which will require family scheduling
• Specific memory handling issues must be managed in order to improve performance
• F_SETBUF must be optimised
• Using local disk or GFS is not critical for operational priority jobs, however the transfer rates favour the GTS
• NFS does not lock files and housekeeping can interfere with running jobs
• <64kB will use the slower NFS rather than GFS
• Striping across multiple disks is recommended to obtain the I/O performance
• NC_BLOCKSIZE is important for netCDF I/O which is critical to OceanMAPS
• Do not use do_tx7 for operational jobs, unreliable and not robust
• BRAN performance was inhibited by the storage of single profile diagnostics at higher temporal frequency. OceanMAPS will need to define the types of outputs that will be permitted to limit the impact to operational performance.

Data management system

• OceanMAPS has made the MARS the central infrastructure for its database and archive requirements
• OceanMAPS has developed OPeNDAP for its servicing needs. OPeNDAP is being considered as a common interface for the databade/archive within the prediction system.
• MARS has not been certified as operational. No operational task currently uses MARS.
• MARS has not been designed as a fail over system and does not have the same level of robustness as the RTDB
• MARS presently has been designed for BUFR and GRIB. None of the I/O used in OceanMAPS uses either of these formats. The dominant format used in OceanMAPS is netCDF. NetCDF also dominates ocean and climate modelling. However, the netCDF file format has not matured to an agreed standard but instead has developed a series of conventions. OceanMAPS has moved to develop its own internal standard to guide all data conversions and preparations.
• NetCDF is stored in MARS through two conversion utilities nc2g and g2nc. These utilities may be extended to conform to the OceanMAPS standard.
• BUFR tables templates are defined by WMO. These templates in general must be extended to accommodate ocean observations.
• Should MARS not be supported operationally by end of 2006, OceanMAPS could be delayed from being certified operational
• OPeNDAP is not currently supported as an operational system

Operational infrastructure

• Operational systems must be tested for “canned” situations
• OceanMAPS is a new system and therefore have no operational canned situations
• BRAN experienced a number of failures which form a basis for canned situations. The failures have been attributed to:
• Large surface winds/momentum fluxes in coastal locations
• Real-time observations for 2005 is being archived for hindcast experiments

Satellite observations

• Topex appears to be unrecoverable
• GFO USNavy is expected to fail in the near future. Implementation of GFO should be given a lower priority
• The topic of assimilating surface velocities, both direct observations and analysed by maximum cross correlation techniques developed by Ian Barton was discussed given the potential vulnerability of the prediction system to further altimeter failures.
• BODAS will need to be tested with these observation types
• The Bureau would need to consider translating Ian Barton’s system into operations
• The additional work required was an impediement for implementation in OceanMAPS version 1. However, should another satellite be lost, this will become a critical activity.
• OceanMAPS analysis system is critically dependent on the sea surface height anomaly observations. The system could be reduced to two instruments if GFO fails. The next altimeter to be launched will be Jason-2 in 2008
• Jason-1 data is being pushed to the Bureau from OCEANIDS successfully with an 8hr delay behind real-time
• ENVISAT is now being received by the Bureau but will have a delay of 3 days behind real-time
• GFO is readily accessed from NOAA with a 3 day delay behind real-time
• How close to real-time can the analysis be made with this density of observations? This issue is critical to the OceanMAPS system and the forecast skill
• Sea surface height anomalies observations are disregarded if the model column is shallower than h_min. In BRAN this h_min was set to 200m. This value has not been evaluated and tuned. Future versions of OceanMAPS should explore this issue to improve the number of observations used
• The Jason-1 observations received by the Bureau have shown some values that are beyond physical bounds. CSIRO have applied in-house quality control procedures for these observations.
• Neville Smith, expressed that the responsibility for quality control of observation streams should be made by the originating agency. It is recommended that dialogue be undertaken with these agencies to see if additional quality control procedures can be included
• It is recommended that quality control procedures be included in OceanMAPS until a change in quality control of the source observations is available
• The Bureau is now receiving tide gauge data from the NTC from an ftp server. The performance of the ftp server does not appear robust enough for operations
• The existing agreements between the NTC and the state authorities for the coastal tide gauge network is believed to not cover Bureau wide applications. OEB has initiated new negotiations. These negotiations are a critical activity.
• The preparation algorithm of the tide gauge observations is on-going and will be compared with those prepared at CSIRO
• The performance of the filtered tide gauge observations have not been fully evaluated in BRAN

Profile observations

• In what form are Argo profiles placed on the GTS? What level of QC?
• Argo netCDF format is the standard format for all profiles for OceanMAPS and POAMA
• Conversion of GTS into the argo format is a critical activity
• USGODAE and Coriolis contain unique observations and have different updating schedules. Both are critical to obtaining the largest set of observations for near real-time analyses.
• The number of duplicates of Argo is very high and will be addressed by a duplicates sorter algorithm.
• USGODAE had a recent multiple day delay in Argo files on the server. The cause needs further investigation and comparisons with GTS and Coriolis
• ENACT QC uses a Baysian cumulative probability approach
• Relative penalties for different tests requires significant tuning
• Specific tunings for FOAM vs Seasonal forecasting system are likely to be necessary
• ENACT negotiations with UKMet are ongoing. It is anticipated that it will not be included in OceanMAPS version 1. Instead the model dependent QC will be an extension of the QC already included in BODAS
• Black listed floats. Argo floats will continue to cycle beyond the instruments life. How will black listed Argo floats be accounted for in the prediction system?

Surface fluxes (NWP)

• GASP stress does not exhibit the same magnitude of fluxes as ECMWF (ECMWF fields generated instabilities in BRAN)
• BRAN instabilities from ECMWF momentum fluxes associated with grid points adjacent to the coastline. Often the coastline also exhibits sharp sloping orography
• BRAN/SPINUP drift in heat content is traced to incorrect fluxes from ERA40
• GASP total heat flux has not been assessed for biases
• GASP has been shown to have poor skill in precipitation in the tropical Pacific (comm. Ebert)
• GASP uses a weekly SST. Impact on the surface fluxes not known
• GASP to OFAM conversion performed by Mansbridge algorithm
• Challenge with temporal changes in the sea-ice mask
• GASP/LAPS blend
• (Kamal) suggested the model development group have programs to combine basic atmospheric fields (not fluxes)
• LAPS has a rapid drop-off in skill (<3days)
• The impact of LAPS skill drop-off will be higher variability in the wrong location. For example tropical cyclones will drive fluxes in potentially the wrong location. BODAS would be required to adjust the mixed layer.
• Peter Oke queried whether it might be beneficial to use a boundary layer model rather than the computed GASP fluxes.
• The assumption that this would improve the response of GASP forecast to the ocean state
• The problem associated with GASP making use of weekly SST
• (Comm. Tim Pugh) some evidence of a positive impact when using POP and NCEP fluxes
• The improvement in response should benefit the short term skill where the atmospheric state remains essentially unchanged from the forecast. This period should be limited as the correction to fluxes is not accounted for through a coupling to GASP
• David Griffin asked why OceanMAPS and GASP were not simply run together if the resources are available to run them both independently
• This is a structure that should be investigated at some point into the future. However, there are a number of potential obstacles.
• OceanMAPS is immature and must establish that it can perform robustly
• OceanMAPS must establish skill in the variables of interest to NWP. Primarily SST. OceanMAPS does not intend to assimilate SST and is unlikely to demonstrate the required skill in this version. Plans for version 2 will assimilate satellite SST. Demonstrating forecast skill for SST would be the first steps to considering coupling.
• OceanMAPS may be too expensive for a coupled NWP forecast delaying the forecast delivery of GASP. However running a coupled GASP/OceanMAPS analysis cycle might prove feasible.

Surface fluxes (SST relaxation)

• Global weekly analysis, why not a higher temporal frequency
• Regional SST not presently used by GASP or LAPS
• Regional SST analysis will migrate to high spatial resolution
• MTSAT may not be included
• 10m foundation recommended. More representative of OFAM which has a top cell of 10m
• SST relaxation has been shown to have some negative feedbacks in BRAN in the eddy-resolved model domain
• Proposition that SST relaxation should be focused on correcting the model drift of the surface layer only and not to correct the high resolution variability
• A correction based on averaging over spatial scales larger than the internal Rossby radius of deformation is proposed for trials
• A correction based on averaging over temporal scales larger than the diurnal variability is also proposed for trials
• SPINUP4 uses a 30 day relaxation period

Proposed operational trials

The implementation plan proposes to conduct operational trials in the following categories. These categories have been restricted to those experiments or tests that contribute to answering specific questions of the system configuration. The detailed analysis of system performance will be performed in phase 3 monitoring.

A Model independent testing

A number of system configuration and control system failure testing of the data management and retrieval systems can be performed without the need for the full cost of OFAM and BODAS. The proposition is to be perform these tests with AusCOM which has reduced costs. It is expected that this can be supported under the current experimental NQS scheduler.

B Robust configuration trials

Testing the robust configuration will include the full OFAM and BODAS software. OFAM has been performed on 3 nodes and 6 node configurations from CSIRO using priority scheduling. The OceanMAPS operational trials will require a minimum of 3 modes in the configuration trials. A higher priority queueing is expected to be necessary for these trials.

C Robust forecast performance tuning

OceanMAPS contains a number of parameters that will require tuning for forecast performance. The present proposal is to perform these experiments by multiple 6month-one year model integrations. A minimum of 3 nodes will be required and priority scheduling required to complete the tests in the operational trial period.

D Multi-node testing

OceanMAPS will be trrialed on a range of node configurations to define the timings relative to resources on the SX6. The results from these experiments will help to define the resource level and the impact to the operational schedule.

E Extended configuration

Experiments to trial alternative algorithms or subroutines for the software, primarily OFAM and BODAS.

The proposed schedule for the operational trials

Trial category	Nov	Dec	Jan	Feb	Mar	Apr	May	Jun	Jul
Model independent trials
Robust configuration
Robust forecast perform.
Multi-node trials
Extended configuration

The following trials are proposed for OceanMAPS based on the outcomes from the workshop. The category and priority of these trials have not been set for this report.

Component	Trial description
OFAM	Hybrid mixed layer tuning
OFAM	Evaluation of no neutral physics
BODAS	Impact of smaller observation windows
BODAS	Impact of asymmetric observation windows
BODAS	Code optimisation
BODAS	Sensitivity of h_min=200m
BODAS	Assimilation of surface velocity observations and MCC fields
OceanMAPS	Determine the period behind real-time for the delayed analysis cycle
OceanMAPS	Determine the size of the observation windows
OceanMAPS	Model state robustness, model drift and reinitialising from a “cold start”
Servicing	OceanMAPS servicing of netCDF output for ROAM
High performance infrastructure	Tuning of the memory layout
Data management system	Data archive control systems for all real-time observations
Data management system	Data retrieval control systems for all real-time observations, surface fluxes and datasets
Operational infrastructure	Trials for “canned” situations
Satellite observations	Trial of data management of near real-time sea surface height anomaly observations
Satellite observations	Assess the density of observations with period behind real-time
Satellite observations	Quality control system
Satellite observations	Trial performance of the filtered tide gauge observations
Profile observations	Conversion of GTS to Argo netCDF format
Profile observations	Duplicate sorter
Profile observations	Model and climatological quality control
Surface fluxes	GASP heat and mass flux biases
Surface fluxes	GASP to OFAM conversion
Surface fluxes	Assessment of boundary layer model fluxes
Surface fluxes	GASP/LAPS blended surface fluxes
Surface fluxes	Blended SST analysis product
Surface fluxes	Trial the spatial averaging relaxation
Surface fluxes	Trial the temporal averaging relaxation

Conclusion

The OceanMAPS STIP workshop achieved many positive outcomes and highlighted a number of issues that the Bureau executive will need to consider as OceanMAPS begins to emerge. The workshop was very well attended over the two days with a good turn over of audience as different specialised sessions occurred. Numerous useful contributions as outlined above were made by the participants. Some of the specific highlights or issues from the workshop included:

Servicing level: RAN expressed an interest in a daily forecast product to provide initial and boundary condition to the ROAM system. This is above the twice per week level agreed in the contract. The higher service level will require up to 3 times the run-time and archive resources from the system proposed at the workshop

Bureau servicing: Only limited progress has been made to define the “basic product set” that the Bureau will provide to the public user community. A wide variety of potential products can be derived from OceanMAPS and the Bureau cannot proceed far without engagement from the user community. There was agreement with services policy branch that it was worthwhile inititiating this activity. Phil Parker is proposing to develop a forum to facilitate this user exchange. Fostering a user community will be critical activity to justifying the current investment and the operational resources.

Operational infrastructure: OceanMAPS is being developed making use of system infrastructure such as MARS and OPeNDAP that are yet to attain operational support. Extended delays to this status will impact OceanMAPS full implementation.

Near real-time observations: Operational oceanography is in its infancy with satellite altimetry available in a “best efforts” basis only. This is a challenging environment for a robust system and a more sophisticated control system will be required to account for a wide range of contingencies.

System vulnerabilities: The recent failure of Topex/Poseidon (although expected) has reminded us of the vulnerability of the ocean prediction system to further satellite failures. Should an additional satellite failure occur during the operational trial period assimilation of surface velocity and MCC values will become a critical activity.

OceanMAPS design: The system is being proposed to have two analysis cycles. A delayed cycle a couple of days behind real-time and a forecast analysis which is closer to real-time. This two level analysis is attempting to make up for inadequacies in the current ocean observing system where many crucial observations can be delayed by 3 days or more behind real-time. This structure adds to the computational cost and will need to be justified by the improved skill of the forecasts.

Optimisation: Assessments of OFAM and BODAS have been made for resource requirements. Optimistically we can expect a halving in costs from those of the SPINUP and BRAN.

Resources: OFAM and BODAS have very large resource requirements on the TX7/SX6 system and in storage. Conducting the operational trials will require special priority queueing.

Appendix A STIP documentation

The full STIP documentation is available online at http://www.bom.gov.au/bmrc/ocean/BLUElink/OceanMAPS/. Below is an outline of the contents of the STIP. Dates refer to document last revision.

1. STIP background document (26 July 2005)

2. Components

2.1 Ocean Forecast Australia Model (OFAM)

2.1.1 OFAM specification (19 October 2005)

2.1.2 OFAM grid specification (19 October 2005)

2.1.3 OFAM landsea mask (19 October 2005)

2.2 BLUElink Ocean Data Assimilation System (BODAS)

2.2.1 BODAS specification (19 October 2005)

2.2.2 BODAS prep (20 October 2005)

2.2.3 BODAS calc

2.2.4 BODAS post

2.3 Satellite observations

2.3.1 Jason-1 (19 October 2005)

2.3.2 ENVISAT

2.3.3 Geosat Follow-On (GFO) (19 October 2005)

2.3.4 Coastal sea level anomalies (19 October 2005)

2.4 Profile observations

2.4.1 ARGO (19 October 2005)

2.5 Surface fluxes

2.5.1 GASP (19 October 2005)

2.5.2 LAPS (19 October 2005)

2.5.3 Surface temperature relaxation (20 October 2005)

2.6 Deep restoring

2.6.1 OFAM deep restoring

3. OceanMAPS System Configuration

3.1 Operational archival management (to archive)

3.1.1 Satellite data archival system (20 October 2005)

3.1.2 Profile data archival system (20 October 2005)

3.1.3 BODAS data archival system (25 October 2005)

3.1.4 OFAM data archival system (24 October 2005)

3.2 Operational retrieval management (from archive)

3.2.1 Satellite data retrieval system (19 October 2005)

3.2.2 Profile data retrieval system (19 October 2005)

3.2.3 NWP data retrieval system

3.2.4 BODAS product retrieval system (25 October 2005)

3.2.5 OFAM product retrieval system (24 October 2005)

3.3 Software System Management

3.3.1 OceanMAPS control system (24 October 2005)

3.3.2 BODAS control system (25 October 2005)

3.3.3 OFAM control system (24 October 2005)

3.4 Analysis and forecast systems

3.4.1 Delayed/symmetric analysis cycle (19 October 2005)

3.4.2 Realtime/asymmetric forecast cycle

4. Data Servicing

4.1 Product delivery mechanisms

4.1.1 MARS retrieval system

4.1.2 OPeNDAP retrieval system

4.1.3 Live Access Server (LAS) system

4.2 Archived Data Products

4.2.1 Observational data products

4.2.2 BODAS model products

4.2.3 OFAM model products

4.2.4 GODAE products

4.3 RAN METOC

4.4 ROAM

5. OceanMAPS verification and validation

5.1 Metrics

5.1.1 Skill scores

5.1.2 Assimilation measures

5.1.3 Mesoscale metrics

5.2 Model intercomparisons

5.2.1 NRL

5.2.2 GODAE partners

5.3 Routine monitoring / system integrity

5.3.1 Observational Profile Data

5.3.2 Observational Satellite Data

5.3.3 NWP Surface Flux diagnostics

5.3.4 Model component diagnostics

5.3.5 IT performance

5.4 Robustness, vulnerabilities, and Strategies

5.4.1 Profile data retrieval analysis

5.4.2 Satellite data retrieval analysis

5.4.3 NWP surface flux analysis

5.4.4 OceanMAPS control system analysis

5.4.5 BODAS control system analysis

5.4.6 OFAM control system analysis

5.4.7 BODAS product archival analysis

5.4.8 OFAM product archival analysis

6. Operational trials

6.1 Model independent

6.2 Robust Configuration

6.3 Robust forecast performance tuning

6.4 Multi-node

6.5 Extended Configuration

Appendix B Workshop timetable

OceanMAPS Science and Technical Implementation Plan Workshop Wednesday 26^th October 2005
Session Times	Discussion Times	Chair/speaker	Topic
9.00	Introduction
	9.00-9.15	Gary Brassington	Workshop welcome and scope
	9.15-9.30	Andreas Schiller	BLUElink introduction
9.30	Ocean services / user community
	9.30-9.45	Rick Bailey	Bureau Ocean Services
	9.45-10.00	Robert Woodham	METOC services
10.00	Morning tea
10.15	Ocean Forecast Australia Model (OFAM)
	10.15-10.30	Andreas Schiller	Design and scientific performance
	10.30-10.45	Russell Fiedler,Tim Pugh	OFAM performance on HPCCC
	10.45-11.10	Gary Brassington (Chair)	OceanMAPS component STIP Trial configuration Trial schedule and monitoring
11.15	BLUElink Ocean Data Assimilation System / Model evaluation
	11.15-11.30	Gary Brassington	Design and performance of BODAS in Bureau
	11.30-11.45	Schiller/Griffin	GODAE metrics / BRAN
	11.30-12.10	Gary Brassington (Chair)	OceanMAPS component STIP Trial configuration
12.15	Lunch
1.00	Ocean Model Analysis and Prediction System (OceanMAPS)
	1.00-1.15	Gary Brassington	System design
	1.15-1.30	Gary Brassington, Tim Pugh	Implementation phases: Infrastructure Tuning Monitoring
	1.30-1.55	Gary Brassington (Chair)	OceanMAPS system STIP Trial configuration Trial schedule and monitoring
2.00	Servicing
	2.00-2.15	Tennessee Leeuwenburg	OPeNDAP: Internal/external access to archived datasets
	2.15-2.30	Peter Craig	ROAM servicing issues
	2.30-2.55	Gary Brassington (Chair)	OceanMAPS infrastructure STIP Trial configuration Trial schedule and Monitoring
3.00	Afternoon tea
3.15	High performance infrastructure
	3.15-3.30	Phil Tannenbaum	HPCCC infrastructure for operations
	3.15-3.45	Tim Pugh	HPCCC infrastructure for OceanMAPS
	3.45-4.10	Gary Brassington (Chair)	OceanMAPS infrastructure STIP Trial configuration Trial schedule and monitoring
OceanMAPS Science and Technical Implementation Plan Workshop Thursday 27^th October 2005
Session Times	Discussion Times	Chair/speaker	Topic
9.00	Data management system
	9.00-9.15	Graham Warren	Infrastructure
	9.15-9.30	Mikhail Entel, Tan Le	MARS
	9.30-9.55	Gary Brassington (Chair)	OceanMAPS infrastructure STIP Trial configuration Trial schedule and monitoring
10.00	Morning tea
10.15	Operational infrastructure
	10.15-10.30	Graham Warren	NMOC systems: path to operational implementation
	10.30-10.45	Tim Pugh	SMS and operational scheduler
	10.45-10.55	Gary Brassington (Chair)	OceanMAPS STIP Trial configuration Trial schedule and Monitoring
11.00	Satellite observations
	11.00-11.15	Mikhail Entel, David Griffin	Satellite altimeters, sea level anomalies and coastal tide gauge
	11.15-11.30	Mikhail Entel	Near real-time observations (Servers)
	11.30-11.55	Gary Brassington (Chair)	OceanMAPS component STIP Trial configuration Trial schedule and monitoring
12.00	Lunch
1.00	Profile observations
	1.00-1.20	Claire Spillman	Argo and duplicate checker
	1.20-1.30	Oscar Alves, Gary Brassington	Quality control
	1.30-1.55	Gary Brassington (Chair)	OceanMAPS component STIP Trial configuration Trial schedule and monitoring
2.00	Surface fluxes
	2.00-2.15	Eric Schulz	GASP/LAPS
	2.15-2.30	Helen Beggs	Surface temperature relaxation
	2.30-2.55	Gary Brassington (Chair)	OceanMAPS system STIP Trial configuration Trial schedule and monitoring
3.00	Afternoon tea
3.00	Workshop review
	3.00-3.30	Gary Brassington	Workshop summary and close