Changes between Version 5 and Version 6 of WorkingGroups/TAM/ReferenceManual/Introduction

Timestamp:

2010-01-15T15:16:36+01:00 (14 years ago)

Author:

cdlod

Comment:

--

WorkingGroups/TAM/ReferenceManual/Introduction

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