Changes between Version 3 and Version 4 of WorkingGroups/TAM/ReferenceManual/Introduction

Timestamp:

2010-01-15T14:48:57+01:00 (14 years ago)

Author:

cdlod

Comment:

--

WorkingGroups/TAM/ReferenceManual/Introduction

@@ -19 +19 @@
 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.