New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
WorkingGroups/TAM/ReferenceManual/Introduction – NEMO
wiki:WorkingGroups/TAM/ReferenceManual/Introduction

Version 4 (modified by cdlod, 14 years ago) (diff)

--

Last edited Timestamp?

NEMO-TAM Reference Manual

1 - Introduction


Abstract

The development of the tangent linear and adjoint models (TAM in the following) of the dynamical core of the NEMO ocean engine (NEMOTAM) is a key objective of the VODA ANR project. TAM are widely used for variational assimilation applications, but they are also powerful tools for the analysis of physical processes, since they can be used for sensitivity analysis, parameter identification and for the computation of characteristic vectors (singular vectors, Liapunov vectors, etc.).

In the framework of VODA, a work package has been set-up in order to develop a comprehensive NEMOTAM package, and to define an effective long-term development strategy for ensuring synchronisation of NEMOTAM with future NEMO releases. This is a heavy task, but it is worth the effort since NEMOTAM will benefit all NEMO users for the wide range of applications described above.

Ideally, this strategy should be defined to allow NEMOTAM to adapt to future NEMO developments as quickly and as efficiently as possible, so that new releases of NEMOTAM can be made soon after new releases of NEMO. This will require careful coordination between the main development teams of NEMO, NEMOTAM and possibly NEMOVAR (INRIA, NEMO Team, CERFACS, ECMWF).

Introduction

The NEMO ocean engine [Madec 2008] was previously known as the OPA model [Madec et al. 1998]. It used to have a TAM (called OPATAM), fully hand-coded and maintained mainly by A. Weaver. OPATAM was initially developed for a Pacific ocean configuration, and targeted at variational data assimilation applications in the framework of OPAVAR [Weaver et al. 2003, 2005]. OPATAM/OPAVAR were extended to other regional basins (Mediterranean sea [Rémy 1999], North Atlantic 1/3° [Forget et al. 2008], South Atlantic 1° ), to the global ocean (ORCA 2° [Daget et al. 2009]), and were used for methodological studies such as control of the 3D model error [Vidard 2001], control of the surface forcing and open boundary conditions [Deltel 2002, Vossepoel et al. 2003]. OPATAM was also used for sensitivity studies [Sévellec et al. 2008], singular vectors [Moore et al. 2003, Sévellec et al. 2009], etc. For several reasons, mainly because of lack of workforce, OPATAM, OPAVAR and related developments were not included in the standard release of OPA. As a consequence, synchronisation of OPATAM with OPA’s releases could not be achieved on a regular basis, and all developments were on individual branches, without feedback to the OPATAM/OPAVAR system. The pool of potential users was reduced consequently. It is important not to repeat this error in the future, so as to ensure that NEMOTAM become a widely used community tool.

The results from this feasibility study demonstrated that TAPENADE was able to produce tangent-linear and adjoint models for NEMO, albeit for a fixed and somewhat simplified configuration (ORCA 2° with all non-differentiable options switched off [Tber et al. 2007]). Even for this simplified configuration, however, substantial human intervention and additional work was required to obtain a useable product from the raw TAPENADE-generated code. Three main drawbacks with TAPENADE were identified for this application. First, the memory management and CPU performance of the raw code were rather poor. Second, the current version of TAPENADE generates single-processor code only and cannot handle directives from the C-PreProcessor? (CPP keys), which are widespread in NEMO. Third, the technique of binomial checkpointing that is used in TAPENADE to handle nonlinearities (see [Tber et al. 2007]) is not compatible, at least in its present implementation, with the incremental algorithm of NEMOVAR, which employs separate executables and (possibly) different resolutions for the outer and inner loops. Improved memory management and extensions to support MPP and CPP keys are planned in future versions of TAPENADE so the first two deficiencies are not fundamental. The third deficiency, however, is more problematic and it is likely that the trajectory management for nonlinearities in NEMOTAM will be done differently from TAPENADE, possibly along the lines of the simpler strategy implemented in OPAVAR. The modifications required to make TAPENADE or whatever other AD tool, compatible with the multi-incremental approach are really substantial and cannot be done in a short or medium term. Moreover the numerical performances of the TAPENADE generated TAM do not allow yet their use for ’big’ configurations and for operational applications.

From that experience it has been decided to go toward the hand-coding approach, the use of AD tool being left aside for the time being. We may reconsider this in a medium or long term though.