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).


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.

A NEMOTAM working group was initiated in the framework of a CNRS/INSU/LEFE ASSIM-2006 project, to investigate the feasibility of using TAPENADE [ Hascoët & Pascual 2004], an AD (automatic differentiation) tool, to speed up the writing of TAM for OPA9, the dynamical ocean component of NEMO. The goal of this working group was twofold. The first goal was to identify the strengths and weaknesses of TAPENADE by applying it directly to the NEMO source code, with as little human intervention as possible, in order to build a NEMOTAM prototype. The second goal was to define, based on the experience deriving the prototype, a strategy for developing a general-purpose NEMOTAM that both respects the NEMO code style/structure and gives acceptable computer performance (in terms of both CPU and memory requirements) for realistic ocean configurations. Providing feedback to the TAPENADE developers was an important aspect of this work to help improve future versions of the TAPENADE software.

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.

Last edited Timestamp?

Last modified 10 years ago Last modified on 2010-06-01T18:07:05+02:00