/[MITgcm]/manual/s_autodiff/text/doc_ad_2.tex
ViewVC logotype

Diff of /manual/s_autodiff/text/doc_ad_2.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph | View Patch Patch

revision 1.13 by heimbach, Fri Jan 18 22:56:45 2002 UTC revision 1.16 by heimbach, Tue May 11 21:55:14 2004 UTC
# Line 557  Because of the local character of the de Line 557  Because of the local character of the de
557  (a derivative is defined w.r.t. a point along the trajectory),  (a derivative is defined w.r.t. a point along the trajectory),
558  the intermediate results of the model trajectory  the intermediate results of the model trajectory
559  $\vec{v}^{(\lambda+1)}={\cal M}_{\lambda}(v^{(\lambda)})$  $\vec{v}^{(\lambda+1)}={\cal M}_{\lambda}(v^{(\lambda)})$
560  are needed to evaluate the intermediate Jacobian  may be required to evaluate the intermediate Jacobian
561  $M_{\lambda}|_{\vec{v}^{(\lambda)}} \, \delta \vec{v}^{(\lambda)} $.  $M_{\lambda}|_{\vec{v}^{(\lambda)}} \, \delta \vec{v}^{(\lambda)} $.
562    This is the case e.g. for nonlinear expressions
563    (momentum advection, nonlinear equation of state), state-dependent
564    conditional statements (parameterization schemes).
565  In the forward mode, the intermediate results are required  In the forward mode, the intermediate results are required
566  in the same order as computed by the full forward model ${\cal M}$,  in the same order as computed by the full forward model ${\cal M}$,
567  but in the reverse mode they are required in the reverse order.  but in the reverse mode they are required in the reverse order.
# Line 569  point of evaluation has to be recomputed Line 572  point of evaluation has to be recomputed
572    
573  A method to balance the amount of recomputations vs.  A method to balance the amount of recomputations vs.
574  storage requirements is called {\sf checkpointing}  storage requirements is called {\sf checkpointing}
575  (e.g. \cite{res-eta:98}).  (e.g. \cite{gri:92}, \cite{res-eta:98}).
576  It is depicted in \ref{fig:3levelcheck} for a 3-level checkpointing  It is depicted in \ref{fig:3levelcheck} for a 3-level checkpointing
577  [as an example, we give explicit numbers for a 3-day  [as an example, we give explicit numbers for a 3-day
578  integration with a 1-hourly timestep in square brackets].  integration with a 1-hourly timestep in square brackets].
# Line 580  In a first step, the model trajectory is Line 583  In a first step, the model trajectory is
583  $ {n}^{lev3} $ subsections [$ {n}^{lev3} $=3 1-day intervals],  $ {n}^{lev3} $ subsections [$ {n}^{lev3} $=3 1-day intervals],
584  with the label $lev3$ for this outermost loop.  with the label $lev3$ for this outermost loop.
585  The model is then integrated along the full trajectory,  The model is then integrated along the full trajectory,
586  and the model state stored only at every $ k_{i}^{lev3} $-th timestep  and the model state stored to disk only at every $ k_{i}^{lev3} $-th timestep
587  [i.e. 3 times, at  [i.e. 3 times, at
588  $ i = 0,1,2 $ corresponding to $ k_{i}^{lev3} = 0, 24, 48 $].  $ i = 0,1,2 $ corresponding to $ k_{i}^{lev3} = 0, 24, 48 $].
589    In addition, the cost function is computed, if needed.
590  %  %
591  \item [$lev2$]  \item [$lev2$]
592  In a second step each subsection itself is divided into  In a second step each subsection itself is divided into
593  $ {n}^{lev2} $ sub-subsections  $ {n}^{lev2} $ subsections
594  [$ {n}^{lev2} $=4 6-hour intervals per subsection].  [$ {n}^{lev2} $=4 6-hour intervals per subsection].
595  The model picks up at the last outermost dumped state  The model picks up at the last outermost dumped state
596  $ v_{k_{n}^{lev3}} $ and is integrated forward in time along  $ v_{k_{n}^{lev3}} $ and is integrated forward in time along
597  the last subsection, with the label $lev2$ for this    the last subsection, with the label $lev2$ for this  
598  intermediate loop.  intermediate loop.
599  The model state is now stored at every $ k_{i}^{lev2} $-th  The model state is now stored to disk at every $ k_{i}^{lev2} $-th
600  timestep  timestep
601  [i.e. 4 times, at  [i.e. 4 times, at
602  $ i = 0,1,2,3 $ corresponding to $ k_{i}^{lev2} = 48, 54, 60, 66 $].  $ i = 0,1,2,3 $ corresponding to $ k_{i}^{lev2} = 48, 54, 60, 66 $].
# Line 600  $ i = 0,1,2,3 $ corresponding to $ k_{i} Line 604  $ i = 0,1,2,3 $ corresponding to $ k_{i}
604  \item [$lev1$]  \item [$lev1$]
605  Finally, the model picks up at the last intermediate dump state  Finally, the model picks up at the last intermediate dump state
606  $ v_{k_{n}^{lev2}} $ and is integrated forward in time along  $ v_{k_{n}^{lev2}} $ and is integrated forward in time along
607  the last sub-subsection, with the label $lev1$ for this    the last subsection, with the label $lev1$ for this  
608  intermediate loop.  intermediate loop.
609  Within this sub-subsection only, the model state is stored  Within this sub-subsection only, parts of the model state is stored
610  at every timestep  to memory at every timestep
611  [i.e. every hour $ i=0,...,5$ corresponding to  [i.e. every hour $ i=0,...,5$ corresponding to
612  $ k_{i}^{lev1} = 66, 67, \ldots, 71 $].  $ k_{i}^{lev1} = 66, 67, \ldots, 71 $].
613  Thus, the  final state $ v_n = v_{k_{n}^{lev1}} $ is reached  The  final state $ v_n = v_{k_{n}^{lev1}} $ is reached
614  and the model state of all proceeding timesteps along the last  and the model state of all preceding timesteps along the last
615  sub-subsections are available, enabling integration backwards  innermost subsection are available, enabling integration backwards
616  in time along the last sub-subsection.  in time along the last subsection.
617  Thus, the adjoint can be computed along this last  The adjoint can thus be computed along this last
618  sub-subsection $k_{n}^{lev2}$.  subsection $k_{n}^{lev2}$.
619  %  %
620  \end{itemize}  \end{itemize}
621  %  %
622  This procedure is repeated consecutively for each previous  This procedure is repeated consecutively for each previous
623  sub-subsection $k_{n-1}^{lev2}, \ldots, k_{1}^{lev2} $  subsection $k_{n-1}^{lev2}, \ldots, k_{1}^{lev2} $
624  carrying the adjoint computation to the initial time  carrying the adjoint computation to the initial time
625  of the subsection $k_{n}^{lev3}$.  of the subsection $k_{n}^{lev3}$.
626  Then, the procedure is repeated for the previous subsection  Then, the procedure is repeated for the previous subsection
# Line 627  $k_{1}^{lev3}$. Line 631  $k_{1}^{lev3}$.
631  For the full model trajectory of  For the full model trajectory of
632  $ n^{lev3} \cdot n^{lev2} \cdot n^{lev1} $ timesteps  $ n^{lev3} \cdot n^{lev2} \cdot n^{lev1} $ timesteps
633  the required storing of the model state was significantly reduced to  the required storing of the model state was significantly reduced to
634  $ n^{lev1} + n^{lev2} + n^{lev3} $  $ n^{lev2} + n^{lev3} $ to disk and roughly $ n^{lev1} $ to memory
635  [i.e. for the 3-day integration with a total oof 72 timesteps  [i.e. for the 3-day integration with a total oof 72 timesteps
636  the model state was stored 13 times].  the model state was stored 7 times to disk and roughly 6 times
637    to memory].
638  This saving in memory comes at a cost of a required  This saving in memory comes at a cost of a required
639  3 full forward integrations of the model (one for each  3 full forward integrations of the model (one for each
640  checkpointing level).  checkpointing level).
641  The balance of storage vs. recomputation certainly depends  The optimal balance of storage vs. recomputation certainly depends
642  on the computing resources available.  on the computing resources available and may be adjusted by
643    adjusting the partitioning among the
644    $ n^{lev3}, \,\, n^{lev2}, \,\, n^{lev1} $.
645    
646  \begin{figure}[t!]  \begin{figure}[t!]
647  \begin{center}  \begin{center}
# Line 664  Schematic view of intermediate dump and Line 671  Schematic view of intermediate dump and
671  % \subsection{Error covariance estimate and Hessian matrix}  % \subsection{Error covariance estimate and Hessian matrix}
672  % \label{sec_hessian}  % \label{sec_hessian}
673    
674  \newpage  \newpage
675    
676  %**********************************************************************  %**********************************************************************
677  \section{AD-specific setup by example: sensitivity of carbon sequestration}  \section{TLM and ADM generation in general}
678  \label{sec_ad_setup_ex}  \label{sec_ad_setup_gen}
679  %**********************************************************************  %**********************************************************************
680    
681  The MITGCM has been adapted to enable AD using TAMC or TAF.  In this section we describe in a general fashion
682  The present description, therefore, is specific to the  the parts of the code that are relevant for automatic
683  use of TAMC or TAF as AD tool.  differentiation using the software tool TAF.
 The following sections describe the steps which are necessary to  
 generate a tangent linear or adjoint model of the MITGCM.  
 We take as an example the sensitivity of carbon sequestration  
 in the ocean.  
 The AD-relevant hooks in the code are sketched in  
 \ref{fig:adthemodel}, \ref{fig:adthemain}.  
   
 \subsection{Overview of the experiment}  
   
 We describe an adjoint sensitivity analysis of out-gassing from  
 the ocean into the atmosphere of a carbon-like tracer injected  
 into the ocean interior (see \cite{hil-eta:01}).  
   
 \subsubsection{Passive tracer equation}  
   
 For this work the MITGCM was augmented with a thermodynamically  
 inactive tracer, $C$. Tracer residing in the ocean  
 model surface layer is out-gassed according to a relaxation time scale,  
 $\mu$. Within the ocean interior, the tracer is passively advected  
 by the ocean model currents. The full equation for the time evolution  
 %  
 \begin{equation}  
 \label{carbon_ddt}  
 \frac{\partial C}{\partial t} \, = \,  
 -U\cdot \nabla C \, - \, \mu C \, + \, \Gamma(C) \,+ \, S  
 \end{equation}  
 %  
 also includes a source term $S$. This term  
 represents interior sources of $C$ such as would arise due to  
 direct injection.  
 The velocity term, $U$, is the sum of the  
 model Eulerian circulation and an eddy-induced velocity, the latter  
 parameterized according to Gent/McWilliams  
 (\cite{gen-mcw:90, gen-eta:95}).  
 The convection function, $\Gamma$, mixes $C$ vertically wherever the  
 fluid is locally statically unstable.  
   
 The out-gassing time scale, $\mu$, in eqn. (\ref{carbon_ddt})  
 is set so that \( 1/\mu \sim 1 \ \mathrm{year} \) for the surface  
 ocean and $\mu=0$ elsewhere. With this value, eqn. (\ref{carbon_ddt})  
 is valid as a prognostic equation for small perturbations in oceanic  
 carbon concentrations. This configuration provides a  
 powerful tool for examining the impact of large-scale ocean circulation  
 on $ CO_2 $ out-gassing due to interior injections.  
 As source we choose a constant in time injection of  
 $ S = 1 \,\, {\rm mol / s}$.  
   
 \subsubsection{Model configuration}  
   
 The model configuration employed has a constant  
 $4^\circ \times 4^\circ$ resolution horizontal grid and realistic  
 geography and bathymetry. Twenty vertical layers are used with  
 vertical spacing ranging  
 from 50 m near the surface to 815 m at depth.  
 Driven to steady-state by climatological wind-stress, heat and  
 fresh-water forcing the model reproduces well known large-scale  
 features of the ocean general circulation.  
   
 \subsubsection{Out-gassing cost function}  
   
 To quantify and understand out-gassing due to injections of $C$  
 in eqn. (\ref{carbon_ddt}),  
 we define a cost function $ {\cal J} $ that measures the total amount of  
 tracer out-gassed at each timestep:  
 %  
 \begin{equation}  
 \label{cost_tracer}  
 {\cal J}(t=T)=\int_{t=0}^{t=T}\int_{A} \mu C \, dA \, dt  
 \end{equation}  
 %  
 Equation(\ref{cost_tracer}) integrates the out-gassing term, $\mu C$,  
 from (\ref{carbon_ddt})  
 over the entire ocean surface area, $A$, and accumulates it  
 up to time $T$.  
 Physically, ${\cal J}$ can be thought of as representing the amount of  
 $CO_2$ that our model predicts would be out-gassed following an  
 injection at rate $S$.  
 The sensitivity of ${\cal J}$ to the spatial location of $S$,  
 $\frac{\partial {\cal J}}{\partial S}$,  
 can be used to identify regions from which circulation  
 would cause $CO_2$ to rapidly out-gas following injection  
 and regions in which $CO_2$ injections would remain effectively  
 sequestered within the ocean.  
   
 \subsection{Code configuration}  
   
 The model configuration for this experiment resides under the  
 directory {\it verification/carbon/}.  
 The code customization routines are in {\it verification/carbon/code/}:  
 %  
 \begin{itemize}  
 %  
 \item {\it .genmakerc}  
 %  
 \item {\it COST\_CPPOPTIONS.h}  
 %  
 \item {\it CPP\_EEOPTIONS.h}  
 %  
 \item {\it CPP\_OPTIONS.h}  
 %  
 \item {\it CTRL\_OPTIONS.h}  
 %  
 \item {\it ECCO\_OPTIONS.h}  
 %  
 \item {\it SIZE.h}  
 %  
 \item {\it adcommon.h}  
 %  
 \item {\it tamc.h}  
 %  
 \end{itemize}  
 %  
 The runtime flag and parameters settings are contained in  
 {\it verification/carbon/input/},  
 together with the forcing fields and and restart files:  
 %  
 \begin{itemize}  
 %  
 \item {\it data}  
 %  
 \item {\it data.cost}  
 %  
 \item {\it data.ctrl}  
 %  
 \item {\it data.gmredi}  
 %  
 \item {\it data.grdchk}  
 %  
 \item {\it data.optim}  
 %  
 \item {\it data.pkg}  
 %  
 \item {\it eedata}  
 %  
 \item {\it topog.bin}  
 %  
 \item {\it windx.bin, windy.bin}  
 %  
 \item {\it salt.bin, theta.bin}  
 %  
 \item {\it SSS.bin, SST.bin}  
 %  
 \item {\it pickup*}  
 %  
 \end{itemize}  
 %  
 Finally, the file to generate the adjoint code resides in  
 $ adjoint/ $:  
 %  
 \begin{itemize}  
 %  
 \item {\it makefile}  
 %  
 \end{itemize}  
 %  
684    
685  Below we describe the customizations of this files which are  \input{part5/doc_ad_the_model}
 specific to this experiment.  
686    
687  \subsubsection{File {\it .genmakerc}}  The basic flow is depicted in \ref{fig:adthemodel}.
688  This file overwrites default settings of {\it genmake}.  If CPP option {\tt ALLOW\_AUTODIFF\_TAMC} is defined, the driver routine
689  In the present example it is used to switch on the following  {\it the\_model\_main}, instead of calling {\it the\_main\_loop},
690  packages which are related to automatic differentiation  invokes the adjoint of this routine, {\it adthe\_main\_loop},
691  and are disabled by default: \\  which is the toplevel routine in terms of automatic differentiation.
692  \hspace*{4ex} {\tt set ENABLE=( autodiff cost ctrl ecco gmredi grdchk kpp )}  \\  The routine {\it adthe\_main\_loop} has been generated by TAF.
693  Other packages which are not needed are switched off: \\  It contains both the forward integration of the full model, the
694  \hspace*{4ex} {\tt set DISABLE=( aim obcs zonal\_filt shap\_filt cal exf )}  cost function calculation,
695    any additional storing that is required for efficient checkpointing,
696  \subsubsection{File {\it COST\_CPPOPTIONS.h,  CTRL\_OPTIONS.h}}  and the reverse integration of the adjoint model.
   
 These files used to contain package-specific CPP-options  
 (see Section \ref{???}).  
 For technical reasons those options have been grouped together  
 in the file {\it ECCO\_OPTIONS.h}.  
 To retain the modularity, the files have been kept and contain  
 the standard include of the {\it CPP\_OPTIONS.h} file.  
   
 \subsubsection{File {\it CPP\_EEOPTIONS.h}}  
   
 This file contains 'wrapper'-specific CPP options.  
 It only needs to be changed if the code is to be run  
 in a parallel environment (see Section \ref{???}).  
   
 \subsubsection{File {\it CPP\_OPTIONS.h}}  
   
 This file contains model-specific CPP options  
 (see Section \ref{???}).  
 Most options are related to the forward model setup.  
 They are identical to the global steady circulation setup of  
 {\it verification/exp2/}.  
 The three options specific to this experiment are \\  
 \hspace*{4ex} {\tt \#define ALLOW\_PASSIVE\_TRACER} \\  
 This flag enables the code to carry through the  
 advection/diffusion of a passive tracer along the  
 model integration. \\  
 \hspace*{4ex} {\tt \#define ALLOW\_MIT\_ADJOINT\_RUN} \\  
 This flag enables the inclusion of some AD-related fields  
 concerning initialization, link between control variables  
 and forward model variables, and the call to the top-level  
 forward/adjoint subroutine {\it adthe\_main\_loop}  
 instead of {\it the\_main\_loop}. \\  
 \hspace*{4ex} {\tt \#define ALLOW\_GRADIENT\_CHECK} \\  
 This flag enables the gradient check package.  
 After computing the unperturbed cost function and its gradient,  
 a series of computations are performed for which \\  
 $\bullet$ an element of the control vector is perturbed \\  
 $\bullet$ the cost function w.r.t. the perturbed element is  
 computed \\  
 $\bullet$ the difference between the perturbed and unperturbed  
 cost function is computed to compute the finite difference gradient \\  
 $\bullet$ the finite difference gradient is compared with the  
 adjoint-generated gradient.  
 The gradient check package is further described in Section ???.  
697    
698  \subsubsection{File {\it ECCO\_OPTIONS.h}}  [DESCRIBE IN A SEPARATE SECTION THE WORKING OF THE TLM]
699    
700  The CPP options of several AD-related packages are grouped  In Fig. \ref{fig:adthemodel}
701  in this file:  the structure of {\it adthe\_main\_loop} has been strongly
702    simplified to focus on the essentials; in particular, no checkpointing
703    procedures are shown here.
704    Prior to the call of {\it adthe\_main\_loop}, the routine
705    {\it ctrl\_unpack} is invoked to unpack the control vector
706    or initialise the control variables.
707    Following the call of {\it adthe\_main\_loop},
708    the routine {\it ctrl\_pack}
709    is invoked to pack the control vector
710    (cf. Section \ref{section_ctrl}).
711    If gradient checks are to be performed, the option
712    {\tt ALLOW\_GRADIENT\_CHECK} is defined. In this case
713    the driver routine {\it grdchk\_main} is called after
714    the gradient has been computed via the adjoint
715    (cf. Section \ref{section_grdchk}).
716    
717    %------------------------------------------------------------------
718    
719    \subsection{General setup
720    \label{section_ad_setup}}
721    
722    In order to configure AD-related setups the following packages need
723    to be enabled:
724    {\it
725    \begin{table}[h!]
726    \begin{tabular}{l}
727    autodiff \\
728    ctrl \\
729    cost \\
730    grdchk \\
731    \end{tabular}
732    \end{table}
733    }
734    The packages are enabled by adding them to your experiment-specific
735    configuration file
736    {\it packages.conf} (see Section ???).
737    
738    The following AD-specific CPP option files need to be customized:
739  %  %
740  \begin{itemize}  \begin{itemize}
741  %  %
742  \item  \item {\it ECCO\_CPPOPTIONS.h} \\
743  Adjoint support package: {\it pkg/autodiff/} \\  This header file collects CPP options for the packages
744  This package contains hand-written adjoint code such as  {\it autodiff, cost, ctrl} as well as AD-unrelated options for
745  active file handling, flow directives for files which must not  the external forcing package {\it exf}.
746  be differentiated, and TAMC-specific header files. \\  \footnote{NOTE: These options are not set in their package-specific
747  \hspace*{4ex} {\tt \#define ALLOW\_AUTODIFF\_TAMC} \\  headers such as {\it COST\_CPPOPTIONS.h}, but are instead collected
748  defines TAMC-related features in the code. \\  in the single header file {\it ECCO\_CPPOPTIONS.h}.
749  \hspace*{4ex} {\tt \#define ALLOW\_TAMC\_CHECKPOINTING} \\  The package-specific header files serve as simple
750  enables the checkpointing feature of TAMC  placeholders at this point.}
751  (see Section \ref{???}).  %
752  In the present example a 3-level checkpointing is implemented.  \item {\it tamc.h} \\
753  The code contains the relevant store directives, common block  This header configures the splitting of the time stepping loop
754  and tape initializations, storing key computation,  w.r.t. the 3-level checkpointing (see section ???).
755  and loop index handling.  
 The checkpointing length at each level is defined in  
 file {\it tamc.h}, cf. below.  
 %  
 \item Cost function package: {\it pkg/cost/} \\  
 This package contains all relevant routines for  
 initializing, accumulating and finalizing the cost function  
 (see Section \ref{???}). \\  
 \hspace*{4ex} {\tt \#define ALLOW\_COST} \\  
 enables all general aspects of the cost function handling,  
 in particular the hooks in the forward code for  
 initializing, accumulating and finalizing the cost function. \\  
 \hspace*{4ex} {\tt \#define ALLOW\_COST\_TRACER} \\  
 includes the call to the cost function for this  
 particular experiment, eqn. (\ref{cost_tracer}).  
 %  
 \item Control variable package: {\it pkg/ctrl/} \\  
 This package contains all relevant routines for  
 the handling of the control vector.  
 Each control variable can be enabled/disabled with its own flag: \\  
 \begin{tabular}{ll}  
 \hspace*{2ex} {\tt \#define ALLOW\_THETA0\_CONTROL} &  
 initial temperature \\  
 \hspace*{2ex} {\tt \#define ALLOW\_SALT0\_CONTROL} &  
 initial salinity \\  
 \hspace*{2ex} {\tt \#define ALLOW\_TR0\_CONTROL} &  
 initial passive tracer concentration \\  
 \hspace*{2ex} {\tt \#define ALLOW\_TAUU0\_CONTROL} &  
 zonal wind stress \\  
 \hspace*{2ex} {\tt \#define ALLOW\_TAUV0\_CONTROL} &  
 meridional wind stress \\  
 \hspace*{2ex} {\tt \#define ALLOW\_SFLUX0\_CONTROL} &  
 freshwater flux \\  
 \hspace*{2ex} {\tt \#define ALLOW\_HFLUX0\_CONTROL} &  
 heat flux \\  
 \hspace*{2ex} {\tt \#define ALLOW\_DIFFKR\_CONTROL} &  
 diapycnal diffusivity \\  
 \hspace*{2ex} {\tt \#undef ALLOW\_KAPPAGM\_CONTROL} &  
 isopycnal diffusivity \\  
 \end{tabular}  
756  %  %
757  \end{itemize}  \end{itemize}
758    
759  \subsubsection{File {\it SIZE.h}}  %------------------------------------------------------------------
760    
761  The file contains the grid point dimensions of the forward  \subsection{Building the AD code
762  model. It is identical to the {\it verification/exp2/}: \\  \label{section_ad_build}}
763  \hspace*{4ex} {\tt sNx = 90} \\  
764  \hspace*{4ex} {\tt sNy = 40} \\  The build process of an AD code is very similar to building
765  \hspace*{4ex} {\tt Nr = 20} \\  the forward model. However, depending on which AD code one wishes
766  It corresponds to a single-tile/single-processor setup:  to generate, and on which AD tool is available (TAF or TAMC),
767  {\tt nSx = nSy = 1, nPx = nPy = 1},  the following {\tt make} targets are available:
768  with standard overlap dimensioning  
769  {\tt OLx = OLy = 3}.  \begin{table}[h!]
770    {\footnotesize
771  \subsubsection{File {\it adcommon.h}}  \begin{tabular}{ccll}
772    ~ & {\it AD-target} & {\it output} & {\it description} \\
773  This file contains common blocks of some adjoint variables  \hline
774  that are generated by TAMC.  \hline
775  The common blocks are used by the adjoint support routine  (1) & {\tt <MODE><TOOL>only} & {\tt <MODE>\_<TOOL>\_output.f}  &
776  {\it addummy\_in\_stepping} which needs to access those variables:  generates code for $<$MODE$>$ using $<$TOOL$>$ \\
777    ~ & ~ & ~ & no {\tt make} dependencies on {\tt .F .h} \\
778  \begin{tabular}{ll}  ~ & ~ & ~ & useful for compiling on remote platforms \\
779  \hspace*{4ex} {\tt common /addynvars\_r/} &  \hline
780  \hspace*{4ex} is related to {\it DYNVARS.h} \\  (2) & {\tt <MODE><TOOL>} & {\tt <MODE>\_<TOOL>\_output.f}  &
781  \hspace*{4ex} {\tt common /addynvars\_cd/} &  generates code for $<$MODE$>$ using $<$TOOL$>$ \\
782  \hspace*{4ex} is related to {\it DYNVARS.h} \\  ~ & ~ & ~ & includes {\tt make} dependencies on {\tt .F .h} \\
783  \hspace*{4ex} {\tt common /addynvars\_diffkr/} &  ~ & ~ & ~ & i.e. input for $<$TOOL$>$ may be re-generated \\
784  \hspace*{4ex} is related to {\it DYNVARS.h} \\  \hline
785  \hspace*{4ex} {\tt common /addynvars\_kapgm/} &  (3) & {\tt <MODE>all} & {\tt mitgcmuv\_<MODE>}  &
786  \hspace*{4ex} is related to {\it DYNVARS.h} \\  generates code for $<$MODE$>$ using $<$TOOL$>$ \\
787  \hspace*{4ex} {\tt common /adtr1\_r/} &  ~ & ~ & ~ & and compiles all code \\
788  \hspace*{4ex} is related to {\it TR1.h} \\  ~ & ~ & ~ & (use of TAF is set as default) \\
789  \hspace*{4ex} {\tt common /adffields/} &  \hline
790  \hspace*{4ex} is related to {\it FFIELDS.h}\\  \hline
791  \end{tabular}  \end{tabular}
792    }
793  Note that if the structure of the common block changes in the  \end{table}
794  above header files of the forward code, the structure  %
795  of the adjoint common blocks will change accordingly.  Here, the following placeholders are used
 Thus, it has to be made sure that the structure of the  
 adjoint common block in the hand-written file {\it adcommon.h}  
 complies with the automatically generated adjoint common blocks  
 in {\it adjoint\_model.F}.  
   
 \subsubsection{File {\it tamc.h}}  
   
 This routine contains the dimensions for TAMC checkpointing.  
796  %  %
797  \begin{itemize}  \begin{itemize}
798  %  %
799  \item {\tt \#ifdef ALLOW\_TAMC\_CHECKPOINTING} \\  \item [$<$TOOL$>$]
 3-level checkpointing is enabled, i.e. the timestepping  
 is divided into three different levels (see Section \ref{???}).  
 The model state of the outermost ({\tt nchklev\_3}) and the  
 intermediate ({\tt nchklev\_2}) timestepping loop are stored to file  
 (handled in {\it the\_main\_loop}).  
 The innermost loop ({\tt nchklev\_1})  
 avoids I/O by storing all required variables  
 to common blocks. This storing may also be necessary if  
 no checkpointing is chosen  
 (nonlinear functions, if-statements, iterative loops, ...).  
 In the present example the dimensions are chosen as follows: \\  
 \hspace*{4ex} {\tt nchklev\_1      =  36 } \\  
 \hspace*{4ex} {\tt nchklev\_2      =  30 } \\  
 \hspace*{4ex} {\tt nchklev\_3      =  60 } \\  
 To guarantee that the checkpointing intervals span the entire  
 integration period the following relation must be satisfied: \\  
 \hspace*{4ex} {\tt nchklev\_1*nchklev\_2*nchklev\_3 $ \ge $ nTimeSteps} \\  
 where {\tt nTimeSteps} is either specified in {\it data}  
 or computed via \\  
 \hspace*{4ex} {\tt nTimeSteps = (endTime-startTime)/deltaTClock }.  
 %  
 \item {\tt \#undef ALLOW\_TAMC\_CHECKPOINTING} \\  
 No checkpointing is enabled.  
 In this case the relevant counter is {\tt nchklev\_0}.  
 Similar to above, the following relation has to be satisfied \\  
 \hspace*{4ex} {\tt nchklev\_0 $ \ge $ nTimeSteps}.  
800  %  %
801  \end{itemize}  \begin{itemize}
   
 The following parameters may be worth describing: \\  
802  %  %
803  \hspace*{4ex} {\tt isbyte} \\  \item {\tt TAF}
804  \hspace*{4ex} {\tt maxpass} \\  \item {\tt TAMC}
 ~  
   
 \subsubsection{File {\it makefile}}  
   
 This file contains all relevant parameter flags and  
 lists to run TAMC or TAF.  
 It is assumed that TAMC is available to you, either locally,  
 being installed on your network, or remotely through the 'TAMC Utility'.  
 TAMC is called with the command {\tt tamc} followed by a  
 number of options. They are described in detail in the  
 TAMC manual \cite{gie:99}.  
 Here we briefly discuss the main flags used in the {\it makefile}  
805  %  %
 \begin{itemize}  
 \item [{\tt tamc}] {\tt  
 -input <variable names>  
 -output <variable name> -r4 ... \\  
 -toplevel <S/R name> -reverse <file names>  
 }  
806  \end{itemize}  \end{itemize}
807  %  %
808    \item [$<$MODE$>$]
809    %
810  \begin{itemize}  \begin{itemize}
811  %  %
812  \item {\tt -toplevel <S/R name>} \\  \item {\tt ad} generates the adjoint model (ADM)
813  Name of the toplevel routine, with respect to which the  \item {\tt ftl} generates the tangent linear model (TLM)
814  control flow analysis is performed.  \item {\tt svd} generates both ADM and TLM for \\
815  %  singular value decomposition (SVD) type calculations
 \item {\tt -input <variable names>} \\  
 List of independent variables $ u $ with respect to which the  
 dependent variable $ J $ is differentiated.  
 %  
 \item {\tt -output <variable name>} \\  
 Dependent variable $ J $  which is to be differentiated.  
 %  
 \item {\tt -reverse <file names>} \\  
 Adjoint code is generated to compute the sensitivity of an  
 independent variable w.r.t.  many dependent variables.  
 In the discussion of Section ???  
 the generated adjoint top-level routine computes the product  
 of the transposed Jacobian matrix $ M^T $ times  
 the gradient vector $ \nabla_v J $.  
 \\  
 {\tt <file names>} refers to the list of files {\it .f} which are to be  
 analyzed by TAMC. This list is generally smaller than the full list  
 of code to be compiled. The files not contained are either  
 above the top-level routine (some initializations), or are  
 deliberately hidden from TAMC, either because hand-written  
 adjoint routines exist, or the routines must not (or don't have to)  
 be differentiated. For each routine which is part of the flow tree  
 of the top-level routine, but deliberately hidden from TAMC  
 (or for each package which contains such routines),  
 a corresponding file {\it .flow} exists containing flow directives  
 for TAMC.  
816  %  %
817  \item {\tt -r4} \\  \end{itemize}
 ~  
818  %  %
819  \end{itemize}  \end{itemize}
820    
821    For example, to generate the adjoint model using TAF after routines ({\tt .F})
822    or headers ({\tt .h}) have been modified, but without compilation,
823    type {\tt make adtaf};
824    or, to generate the tangent linear model using TAMC without
825    re-generating the input code, type {\tt make ftltamconly}.
826    
 \subsubsection{The input parameter files}  
   
 \paragraph{File {\it data}}  
   
 \paragraph{File {\it data.cost}}  
   
 \paragraph{File {\it data.ctrl}}  
   
 \paragraph{File {\it data.gmredi}}  
   
 \paragraph{File {\it data.grdchk}}  
   
 \paragraph{File {\it data.optim}}  
827    
828  \paragraph{File {\it data.pkg}}  A typical full build process to generate the ADM via TAF would
829    look like follows:
830  \paragraph{File {\it eedata}}  \begin{verbatim}
831    % mkdir build
832  \paragraph{File {\it topog.bin}}  % cd build
833    % ../../../tools/genmake2 -mods=../code_ad
834  \paragraph{File {\it windx.bin, windy.bin}}  % make depend
835    % make adall
836  \paragraph{File {\it salt.bin, theta.bin}}  \end{verbatim}
   
 \paragraph{File {\it SSS.bin, SST.bin}}  
   
 \paragraph{File {\it pickup*}}  
   
 \subsection{Compiling the model and its adjoint}  
837    
838  The built process of the adjoint model is slightly more  %------------------------------------------------------------------
 complex than that of compiling the forward code.  
 The main reason is that the adjoint code generation requires  
 a specific list of routines that are to be differentiated  
 (as opposed to the automatic generation of a list of  
 files to be compiled by genmake).  
 This list excludes routines that don't have to be or must not be  
 differentiated. For some of the latter routines flow directives  
 may be necessary, a list of which has to be given as well.  
 For this reason, a separate {\it makefile} is currently  
 maintained in the directory {\tt adjoint/}. This  
 makefile is responsible for the adjoint code generation.  
839    
840  In the following we describe the build process step by step,  \subsection{The AD build process in detail
841  assuming you are in the directory {\tt bin/}.  \label{section_ad_build_detail}}
 A summary of steps to follow is given at the end.  
842    
843  \paragraph{Adjoint code generation and compilation -- step by step}  The {\tt make <MODE>all} target consists of the following procedures:
844    
845  \begin{enumerate}  \begin{enumerate}
846  %  %
847  \item  \item
848  {\tt ln -s ../verification/???/code/.genmakerc .} \\  A header file {\tt AD\_CONFIG.h} is generated which contains a CPP option
849  {\tt ln -s ../verification/???/code/*.[Fh] .} \\  on which code ought to be generated. Depending on the {\tt make} target,
850  Link your customized genmake options, header files,  the contents is
851  and modified code to the compile directory.  \begin{itemize}
 %  
 \item  
 {\tt ../tools/genmake -makefile} \\  
 Generate your Makefile (cf. Section ???).  
 %  
852  \item  \item
853  {\tt make depend} \\  {\tt \#define ALLOW\_ADJOINT\_RUN}
 Dependency analysis for the CPP pre-compiler (cf. Section ???).  
 %  
854  \item  \item
855  {\tt make small\_f} \\  {\tt \#define ALLOW\_TANGENTLINEAR\_RUN}
 This is the first difference between forward code compilation  
 and adjoint code generation and compilation.  
 Instead of going through the entire compilation process  
 (CPP precompiling -- {\tt .f}, object code generation -- {\tt .o},  
 linking of object files and libraries to generate executable),  
 only the CPP compiler is invoked at this stage to generate  
 the {\tt .f} files.  
 %  
856  \item  \item
857  {\tt cd ../adjoint} \\  {\tt \#define ALLOW\_ECCO\_OPTIMIZATION}
858  {\tt make adtaf} or {\tt make adtamc} \\  \end{itemize}
 Depending on whether you have TAF or TAMC at your disposal,  
 you'll choose {\tt adtaf} or {\tt adtamc} as your  
 make target for the {\it makefile} in the directory {\tt adjoint/}.  
 Several things happen at this stage.  
 %  
 \begin{enumerate}  
859  %  %
860  \item  \item
861  The initial template file {\it adjoint\_model.F} which is part  A single file {\tt <MODE>\_input\_code.f} is concatenated
862  of the compiling list created by {\it genmake} is restored.  consisting of all {\tt .f} files that are part of the list {\bf AD\_FILES}
863    and all {\tt .flow} files that are part of the list {\bf AD\_FLOW\_FILES}.
864  %  %
865  \item  \item
866  All Fortran routines {\tt *.f} in {\tt bin/} are  The AD tool is invoked with the {\bf <MODE>\_<TOOL>\_FLAGS}.
867  concatenated into a single file (it's current name is  The default AD tool flags in {\tt genmake2} can be overrwritten by
868  {\it tamc\_code.f}).  an {\tt adjoint\_options} file (similar to the platform-specific
869    {\tt build\_options}, see Section ???.
870    The AD tool writes the resulting AD code into the file
871    {\tt <MODE>\_input\_code\_ad.f}
872  %  %
873  \item  \item
874  Adjoint code is generated by TAMC or TAF.  A short sed script {\tt adjoint\_sed} is applied to
875  The adjoint code is written to the file {\it tamc\_code\_ad.f}.  {\tt <MODE>\_input\_code\_ad.f}
876  It contains all adjoint routines of the forward routines  to reinstate {\bf myThid} into the CALL argument list of active file I/O.
877  concatenated in {\it tamc\_code.f}.  The result is written to file {\tt <MODE>\_<TOOL>\_output.f}.
 For a given forward routines {\tt subroutine routinename}  
 the adjoint routine is named {\tt adsubroutine routinename}  
 by default (that default can be changed via the flag  
 {\tt -admark <markname>}).  
 Furthermore, it may contain modified code which  
 incorporates the translation of adjoint store directives  
 into specific Fortran code.  
 For a given forward routines {\tt subroutine routinename}  
 the modified routine is named {\tt mdsubroutine routinename}.  
 TAMC or TAF info is written to file  
 {\it tamc\_code.prot} or {\it taf.log}, respectively.  
 %  
 \end{enumerate}  
878  %  %
879  \item  \item
880  {\tt make adchange} \\  All routines are compiled and an executable is generated
881  The multi-threading capability of the MITGCM requires a slight  (see Table ???).
 change in the parameter list of some routines that are related to  
 to active file handling.  
 This post-processing invokes the sed script {\it adjoint\_ecco\_sed.com}  
 to insert the threading counter {\bf myThId} into the parameter list  
 of those subroutines.  
 The resulting code is written to file {\it tamc\_code\_sed\_ad.f}  
 and appended to the file {\it adjoint\_model.F}.  
 This concludes the adjoint code generation.  
 %  
 \item  
 {\tt cd ../bin} \\  
 {\tt make} \\  
 The file {\it adjoint\_model.F} now contains the full adjoint code.  
 All routines are now compiled.  
882  %  %
883  \end{enumerate}  \end{enumerate}
884    
885  \paragraph{Adjoint code generation and compilation -- summary}  \subsubsection{The list AD\_FILES and {\tt .list} files}
 ~ \\  
886    
887  \[  Not all routines are presented to the AD tool.
888  \boxed{  Routines typically hidden are diagnostics routines which
889  \begin{split}  do not influence the cost function, but may create
890   ~ & \mbox{\tt cd bin} \\  artificial flow dependencies such as I/O of active variables.
891   ~ & \mbox{\tt ln -s ../verification/my\_experiment/code/.genmakerc .} \\  
892   ~ & \mbox{\tt ln -s ../verification/my\_experiment/code/*.[Fh] .} \\  {\tt genmake2} generates a list (or variable) {\bf AD\_FILES}
893   ~ & \mbox{\tt ../tools/genmake -makefile} \\  which contains all routines that are shown to the AD tool.
894   ~ & \mbox{\tt make depend} \\  This list is put together from all files with suffix {\tt .list}
895   ~ & \mbox{\tt make small\_f} \\  that {\tt genmake2} finds in its search directories.
896   ~ & \mbox{\tt cd ../adjoint} \\  The list file for the core MITgcm routines is in {\tt model/src/}
897   ~ & \mbox{\tt make adtaf <OR: make adtamc>} \\  is called {\tt model\_ad\_diff.list}.
898   ~ & \mbox{\tt make adchange} \\  Note that no wrapper routine is shown to TAF. These are either
899   ~ & \mbox{\tt cd ../bin} \\  not visible at all to the AD code, or hand-written AD code
900   ~ & \mbox{\tt make} \\  is available (see next section).
901  \end{split}  
902  }  Each package directory contains its package-specific
903  \]  list file {\tt <PKG>\_ad\_diff.list}. For example,
904    {\tt pkg/ptracers/} contains the file {\tt ptracers\_ad\_diff.list}.
905    Thus, enabling a package will automatically extend the
906    {\bf AD\_FILES} list of {\tt genmake2} to incorporate the
907    package-specific routines.
908    Note that you will need to regenerate the {\tt Makefile} if
909    you enable a package (e.g. by adding it to {\tt packages.conf})
910    and a {\tt Makefile} already exists.
911    
912    \subsubsection{The list AD\_FLOW\_FILES and {\tt .flow} files}
913    
914    TAMC and TAF can evaluate user-specified directives
915    that start with a specific syntax ({\tt CADJ}, {\tt C\$TAF}, {\tt !\$TAF}).
916    The main categories of directives are STORE directives and
917    FLOW directives. Here, we are concerned with flow directives,
918    store directives are treated elsewhere.
919    
920    Flow directives enable the AD tool to evaluate how it should treat
921    routines that are 'hidden' by the user, i.e. routines which are
922    not contained in the {\bf AD\_FILES} list (see previous section),
923    but which are called in part of the code that the AD tool does see.
924    The flow directive tell the AD tool
925    %
926    \begin{itemize}
927    %
928    \item which subroutine arguments are input/output
929    \item which subroutine arguments are active
930    \item which subroutine arguments are required to compute the cost
931    \item which subroutine arguments are dependent
932    %
933    \end{itemize}
934    %
935    The syntax for the flow directives can be found in the
936    AD tool manuals.
937    
938    {\tt genmake2} generates a list (or variable) {\bf AD\_FLOW\_FILES}
939    which contains all files with suffix{\tt .flow} that it finds
940    in its search directories.
941    The flow directives for the core MITgcm routines of
942    {\tt eesupp/src/} and {\tt model/src/}
943    reside in {\tt pkg/autodiff/}.
944    This directory also contains hand-written adjoint code
945    for the MITgcm WRAPPER (see Section ???).
946    
947    Flow directives for package-specific routines are contained in
948    the corresponding package directories in the file
949    {\tt <PKG>\_ad.flow}, e.g. ptracers-specific directives are in
950    {\tt ptracers\_ad.flow}.
951    
952    \subsubsection{Store directives for 3-level checkpointing}
953    
954    The storing that is required at each period of the
955    3-level checkpointing is controled by three
956    top-level headers.
957    
958  \newpage  \begin{verbatim}
959    do ilev_3 = 1, nchklev_3
960    #  include ``checkpoint_lev3.h''
961       do ilev_2 = 1, nchklev_2
962    #     include ``checkpoint_lev2.h''
963          do ilev_1 = 1, nchklev_1
964    #        include ``checkpoint_lev1.h''
965    
966    ...
967    
968          end do
969       end do
970    end do
971    \end{verbatim}
972    
973  %**********************************************************************  All files {\tt checkpoint\_lev?.h} are contained in directory
974  \section{TLM and ADM generation in general}  {\tt pkg/autodiff/}.
 \label{sec_ad_setup_gen}  
 %**********************************************************************  
975    
 In this section we describe in a general fashion  
 the parts of the code that are relevant for automatic  
 differentiation using the software tool TAMC.  
976    
977  \input{part5/doc_ad_the_model}  \subsubsection{Changing the default AD tool flags: ad\_options files}
978    
979  The basic flow is depicted in \ref{fig:adthemodel}.  
980  If the option {\tt ALLOW\_AUTODIFF\_TAMC} is defined, the driver routine  \subsubsection{Hand-written adjoint code}
981  {\it the\_model\_main}, instead of calling {\it the\_main\_loop},  
982  invokes the adjoint of this routine, {\it adthe\_main\_loop},  %------------------------------------------------------------------
 which is the toplevel routine in terms of reverse mode computation.  
 The routine {\it adthe\_main\_loop} has been generated using TAMC.  
 It contains both the forward integration of the full model,  
 any additional storing that is required for efficient checkpointing,  
 and the reverse integration of the adjoint model.  
 The structure of {\it adthe\_main\_loop} has been strongly  
 simplified for clarification; in particular, no checkpointing  
 procedures are shown here.  
 Prior to the call of {\it adthe\_main\_loop}, the routine  
 {\it ctrl\_unpack} is invoked to unpack the control vector,  
 and following that call, the routine {\it ctrl\_pack}  
 is invoked to pack the control vector  
 (cf. Section \ref{section_ctrl}).  
 If gradient checks are to be performed, the option  
 {\tt ALLOW\_GRADIENT\_CHECK} is defined. In this case  
 the driver routine {\it grdchk\_main} is called after  
 the gradient has been computed via the adjoint  
 (cf. Section \ref{section_grdchk}).  
983    
984  \subsection{The cost function (dependent variable)  \subsection{The cost function (dependent variable)
985  \label{section_cost}}  \label{section_cost}}
# Line 1289  the gradient has been computed via the a Line 987  the gradient has been computed via the a
987  The cost function $ {\cal J} $ is referred to as the {\sf dependent variable}.  The cost function $ {\cal J} $ is referred to as the {\sf dependent variable}.
988  It is a function of the input variables $ \vec{u} $ via the composition  It is a function of the input variables $ \vec{u} $ via the composition
989  $ {\cal J}(\vec{u}) \, = \, {\cal J}(M(\vec{u})) $.  $ {\cal J}(\vec{u}) \, = \, {\cal J}(M(\vec{u})) $.
990  The input is referred to as the  The input are referred to as the
991  {\sf independent variables} or {\sf control variables}.  {\sf independent variables} or {\sf control variables}.
992  All aspects relevant to the treatment of the cost function $ {\cal J} $  All aspects relevant to the treatment of the cost function $ {\cal J} $
993  (parameter setting, initialization, accumulation,  (parameter setting, initialization, accumulation,
994  final evaluation), are controlled by the package {\it pkg/cost}.  final evaluation), are controlled by the package {\it pkg/cost}.
995    The aspects relevant to the treatment of the independent variables
996    are controlled by the package {\it pkg/ctrl} and will be treated
997    in the next section.
998    
999  \input{part5/doc_cost_flow}  \input{part5/doc_cost_flow}
1000    
1001  \subsubsection{genmake and CPP options}  \subsubsection{Enabling the package}
1002  %  
 \begin{itemize}  
 %  
 \item  
1003  \fbox{  \fbox{
1004  \begin{minipage}{12cm}  \begin{minipage}{12cm}
1005  {\it genmake}, {\it CPP\_OPTIONS.h}, {\it ECCO\_CPPOPTIONS.h}  {\it packages.conf}, {\it ECCO\_CPPOPTIONS.h}
1006  \end{minipage}  \end{minipage}
1007  }  }
1008  \end{itemize}  \begin{itemize}
 %  
 The directory {\it pkg/cost} can be included to the  
 compile list in 3 different ways (cf. Section \ref{???}):  
1009  %  %
1010  \begin{enumerate}  \item
1011    The package is enabled by adding {\it cost} to your file {\it packages.conf}
1012    (see Section ???)
1013  %  %
1014  \item {\it genmake}: \\  \item
1015  Change the default settings in the file {\it genmake} by adding  
1016  {\bf cost} to the {\bf enable} list (not recommended).  
1017  %  \end{itemize}
 \item {\it .genmakerc}: \\  
 Customize the settings of {\bf enable}, {\bf disable} which are  
 appropriate for your experiment in the file {\it .genmakerc}  
 and add the file to your compile directory.  
 %  
 \item genmake-options: \\  
 Call {\it genmake} with the option  
 {\tt genmake -enable=cost}.  
1018  %  %
1019  \end{enumerate}  
1020    N.B.: In general the following packages ought to be enabled
1021    simultaneously: {\it autodiff, cost, ctrl}.
1022  The basic CPP option to enable the cost function is {\bf ALLOW\_COST}.  The basic CPP option to enable the cost function is {\bf ALLOW\_COST}.
1023  Each specific cost function contribution has its own option.  Each specific cost function contribution has its own option.
1024  For the present example the option is {\bf ALLOW\_COST\_TRACER}.  For the present example the option is {\bf ALLOW\_COST\_TRACER}.
1025  All cost-specific options are set in {\it ECCO\_CPPOPTIONS.h}  All cost-specific options are set in {\it ECCO\_CPPOPTIONS.h}
1026  Since the cost function is usually used in conjunction with  Since the cost function is usually used in conjunction with
1027  automatic differentiation, the CPP option  automatic differentiation, the CPP option
1028  {\bf ALLOW\_ADJOINT\_RUN} should be defined  {\bf ALLOW\_ADJOINT\_RUN} (file {\it CPP\_OPTIONS.h}) and
1029  (file {\it CPP\_OPTIONS.h}).  {\bf ALLOW\_AUTODIFF\_TAMC} (file {\it ECCO\_CPPOPTIONS.h})
1030    should be defined.
1031    
1032  \subsubsection{Initialization}  \subsubsection{Initialization}
1033  %  %
1034  The initialization of the {\it cost} package is readily enabled  The initialization of the {\it cost} package is readily enabled
1035  as soon as the CPP option {\bf ALLOW\_ADJOINT\_RUN} is defined.  as soon as the CPP option {\bf ALLOW\_COST} is defined.
1036  %  %
1037  \begin{itemize}  \begin{itemize}
1038  %  %
# Line 1414  from each contribution and sums over all Line 1106  from each contribution and sums over all
1106  \begin{equation}  \begin{equation}
1107  {\cal J} \, = \,  {\cal J} \, = \,
1108  {\rm fc} \, = \,  {\rm fc} \, = \,
1109  {\rm mult\_tracer} \sum_{bi,\,bj}^{nSx,\,nSy}  {\rm mult\_tracer} \sum_{\text{global sum}} \sum_{bi,\,bj}^{nSx,\,nSy}
1110  {\rm objf\_tracer}(bi,bj) \, + \, ...  {\rm objf\_tracer}(bi,bj) \, + \, ...
1111  \end{equation}  \end{equation}
1112  %  %
# Line 1462  are controlled by the package {\it pkg/c Line 1154  are controlled by the package {\it pkg/c
1154  %  %
1155  To enable the directory to be included to the compile list,  To enable the directory to be included to the compile list,
1156  {\bf ctrl} has to be added to the {\bf enable} list in  {\bf ctrl} has to be added to the {\bf enable} list in
1157  {\it .genmakerc} (or {\it genmake} itself).  {\it .genmakerc} or in {\it genmake} itself (analogous to {\it cost}
1158    package, cf. previous section).
1159  Each control variable is enabled via its own CPP option  Each control variable is enabled via its own CPP option
1160  in {\it ECCO\_CPPOPTIONS.h}.  in {\it ECCO\_CPPOPTIONS.h}.
1161    
# Line 1606  in the code takes on the form Line 1299  in the code takes on the form
1299  %  %
1300  Note, that reading an active variable corresponds  Note, that reading an active variable corresponds
1301  to a variable assignment. Its derivative corresponds  to a variable assignment. Its derivative corresponds
1302  to a write statement of the adjoint variable.  to a write statement of the adjoint variable, followed by
1303    a reset.
1304  The 'active file' routines have been designed  The 'active file' routines have been designed
1305  to support active read and corresponding adjoint active write  to support active read and corresponding adjoint active write
1306  operations (and vice versa).  operations (and vice versa).
# Line 1723  at intermediate times can be written usi Line 1417  at intermediate times can be written usi
1417  {\it addummy\_in\_stepping}.  {\it addummy\_in\_stepping}.
1418  This routine is part of the adjoint support package  This routine is part of the adjoint support package
1419  {\it pkg/autodiff} (cf.f. below).  {\it pkg/autodiff} (cf.f. below).
1420    The procedure is enabled using via the CPP-option
1421    {\bf ALLOW\_AUTODIFF\_MONITOR} (file {\it ECCO\_CPPOPTIONS.h}).
1422  To be part of the adjoint code, the corresponding S/R  To be part of the adjoint code, the corresponding S/R
1423  {\it dummy\_in\_stepping} has to be called in the forward  {\it dummy\_in\_stepping} has to be called in the forward
1424  model (S/R {\it the\_main\_loop}) at the appropriate place.  model (S/R {\it the\_main\_loop}) at the appropriate place.
1425    The adjoint common blocks are extracted from the adjoint code
1426    via the header file {\it adcommon.h}.
1427    
1428  {\it dummy\_in\_stepping} is essentially empty,  {\it dummy\_in\_stepping} is essentially empty,
1429  the corresponding adjoint routine is hand-written rather  the corresponding adjoint routine is hand-written rather
# Line 1752  the common blocks Line 1450  the common blocks
1450  {\bf /adtr1\_r/}, {\bf /adffields/},  {\bf /adtr1\_r/}, {\bf /adffields/},
1451  which have been extracted from the adjoint code to enable  which have been extracted from the adjoint code to enable
1452  access to the adjoint variables.  access to the adjoint variables.
1453    
1454    {\bf WARNING:} If the structure of the common blocks
1455    {\bf /dynvars\_r/}, {\bf /dynvars\_cd/}, etc., changes
1456    similar changes will occur in the adjoint common blocks.
1457    Therefore, consistency between the TAMC-generated common blocks
1458    and those in {\it adcommon.h} have to be checked.
1459  %  %
1460  \end{itemize}  \end{itemize}
1461    

Legend:
Removed from v.1.13  
changed lines
  Added in v.1.16

  ViewVC Help
Powered by ViewVC 1.1.22