| 1 |
\subsection{Diagnostics--A Flexible Infrastructure} |
\section{Diagnostics--A Flexible Infrastructure} |
| 2 |
\label{sec:pkg:diagnostics} |
\label{sec:pkg:diagnostics} |
| 3 |
\begin{rawhtml} |
\begin{rawhtml} |
| 4 |
<!-- CMIREDIR:package_diagnostics: --> |
<!-- CMIREDIR:package_diagnostics: --> |
| 5 |
\end{rawhtml} |
\end{rawhtml} |
| 6 |
|
|
| 7 |
\subsubsection{Introduction} |
\subsection{Introduction} |
| 8 |
|
|
| 9 |
\noindent |
\noindent |
| 10 |
This section of the documentation describes the Diagnostics package available within |
This section of the documentation describes the Diagnostics package |
| 11 |
the GCM. A large selection of model diagnostics is available for output. |
available within the GCM. A large selection of model diagnostics is |
| 12 |
In addition to the diagnostic quantities pre-defined in the GCM, there exists |
available for output. In addition to the diagnostic quantities |
| 13 |
the option, in any experiment, to define a new diagnostic quantity and include it |
pre-defined in the GCM, there exists the option, in any experiment, to |
| 14 |
as part of the diagnostic output with the addition of a single subroutine call in the |
define a new diagnostic quantity and include it as part of the |
| 15 |
routine where the field is computed. As a matter of philosophy, no diagnostic is enabled |
diagnostic output with the addition of a single subroutine call in the |
| 16 |
as default, thus each user must specify the exact diagnostic information required for an |
routine where the field is computed. As a matter of philosophy, no |
| 17 |
experiment. This is accomplished by enabling the specific diagnostic of interest cataloged |
diagnostic is enabled as default, thus each user must specify the |
| 18 |
in the Diagnostic Menu (see Section \ref{sec:diagnostics:menu}). Instructions for enabling |
exact diagnostic information required for an experiment. This is |
| 19 |
diagnostic output and defining new diagnostic quantities are found in Section |
accomplished by enabling the specific diagnostic of interest cataloged |
| 20 |
|
in the Diagnostic Menu (see Section \ref{sec:diagnostics:menu}). |
| 21 |
|
Instructions for enabling diagnostic output and defining new |
| 22 |
|
diagnostic quantities are found in Section |
| 23 |
\ref{sec:diagnostics:usersguide} of this document. |
\ref{sec:diagnostics:usersguide} of this document. |
| 24 |
|
|
| 25 |
\noindent |
\noindent |
| 26 |
The Diagnostic Menu in this section of the manual is a listing of diagnostic quantities available |
The Diagnostic Menu in this section of the manual is a listing of |
| 27 |
within the main (dynamics) part of the GCM. Additional diagnostic quantities, defined within the |
diagnostic quantities available within the main (dynamics) part of the |
| 28 |
different GCM packages, are available and are listed in the diagnostic menu subsection of |
GCM. Additional diagnostic quantities, defined within the different |
| 29 |
the manual section associated with each relevant package. Once a diagnostic is enabled, the |
GCM packages, are available and are listed in the diagnostic menu |
| 30 |
GCM will continually increment an array specifically allocated for that diagnostic whenever the |
subsection of the manual section associated with each relevant |
| 31 |
appropriate quantity is computed. A counter is defined which records how many times each diagnostic |
package. Once a diagnostic is enabled, the GCM will continually |
| 32 |
quantity has been incremented. Several special diagnostics are included in the menu. Quantities |
increment an array specifically allocated for that diagnostic whenever |
| 33 |
refered to as ``Counter Diagnostics'', are defined for selected diagnostics which record the |
the appropriate quantity is computed. A counter is defined which |
| 34 |
frequency at which a diagnostic is incremented separately for each model grid location. |
records how many times each diagnostic quantity has been incremented. |
| 35 |
Quantitied refered to as ``User Diagnostics'' are included in the menu to facilitate |
Several special diagnostics are included in the menu. Quantities |
| 36 |
defining new diagnostics for a particular experiment. |
referred to as ``Counter Diagnostics'', are defined for selected |
| 37 |
|
diagnostics which record the frequency at which a diagnostic is |
| 38 |
|
incremented separately for each model grid location. Quantities |
| 39 |
|
referred to as ``User Diagnostics'' are included in the menu to |
| 40 |
|
facilitate defining new diagnostics for a particular experiment. |
| 41 |
|
|
| 42 |
\subsubsection{Equations} |
\subsection{Equations} |
| 43 |
Not relevant. |
Not relevant. |
| 44 |
|
|
| 45 |
\subsubsection{Key Subroutines and Parameters} |
\subsection{Key Subroutines and Parameters} |
| 46 |
\label{sec:diagnostics:diagover} |
\label{sec:diagnostics:diagover} |
| 47 |
|
|
| 48 |
\noindent |
\noindent |
| 49 |
There are several utilities within the GCM available to users to enable, disable, |
There are several utilities within the GCM available to users to |
| 50 |
clear, write and retrieve model diagnostics, and may be called from any routine. |
enable, disable, clear, write and retrieve model diagnostics, and may |
| 51 |
The available utilities and the CALL sequences are listed below. |
be called from any routine. The available utilities and the CALL |
| 52 |
|
sequences are listed below. |
| 53 |
\noindent |
|
| 54 |
{\bf diagnostics\_fill}: This is the main user interface routine to the diagnostics |
\noindent |
| 55 |
package. This routine will increment the specified diagnostic quantity with a field |
{\bf DIAGNOSTICS\_ADDTOLIST} |
| 56 |
sent through the argument list. |
(\filelink{pkg/diagnostics/diagnostics\_addtolist.F}{pkg-diagnostics-diagnostics\_addtolist.F}): |
| 57 |
|
%This subroutine enables a diagnostic from the Diagnostic Menu, |
| 58 |
\noindent |
%meaning that space is allocated for the |
| 59 |
\begin{tabbing} |
%diagnostic and the model routines will increment the diagnostic value |
| 60 |
XXXXXXXXX\=XXXXXX\= \kill |
%during execution. |
| 61 |
\> call diagnostics\_fill (arrayin, chardiag, levflg, nlevs, \\ |
This routine is the underlying interface routine for defining a new permanent |
| 62 |
\> bibjflg, bi, bj, myThid) \\ |
diagnostic in the main model or in a package. The calling sequence is: |
| 63 |
\\ |
|
| 64 |
where \> arrayin \>= Field to increment diagnostics array \\ |
\begin{verbatim} |
| 65 |
\> chardiag \>= Character *8 expression for diag to fill \\ |
CALL DIAGNOSTICS_ADDTOLIST ( |
| 66 |
\> levflg \>= Integer flag for vertical levels: \\ |
O diagNum, |
| 67 |
\> \>= 0 indicates multiple (nlevs) levels incremented \\ |
I diagName, diagCode, diagUnits, diagTitle, diagMate, |
| 68 |
\> \>= -1 indicates multiple (nlevs) levels incremented, \\ |
I myThid ) |
| 69 |
\> \> but in reverse vertical order \\ |
|
| 70 |
\> \> positive integer - WHICH single level to increment. \\ |
where: |
| 71 |
\> nlevs \>= indicates Number of levels to be filled (1 if levflg gt 0) \\ |
diagNum = diagnostic Id number - Output from routine |
| 72 |
\> bibjflg \>= Integer flag to indicate instructions for bi bj loop \\ |
diagName = name of diagnostic to declare |
| 73 |
\> \>= 0 indicates that the bi-bj loop must be done here \\ |
diagCode = parser code for this diagnostic |
| 74 |
\> \>= 1 indicates that the bi-bj loop is done OUTSIDE \\ |
diagUnits = field units for this diagnostic |
| 75 |
\> \>= 2 indicates that the bi-bj loop is done OUTSIDE \\ |
diagTitle = field description for this diagnostic |
| 76 |
\> \> AND that we have been sent a local array \\ |
diagMate = diagnostic mate number |
| 77 |
\> \> AND that the array has the shadow regions \\ |
myThid = my Thread Id number |
| 78 |
\> \>= 3 indicates that the bi-bj loop is done OUTSIDE \\ |
|
| 79 |
\> \> AND that we have been sent a local array \\ |
\end{verbatim} |
| 80 |
\> \> AND that the array has no shadow regions \\ |
|
| 81 |
\> bi \>= X-direction process(or) number - used for bibjflg=1-3 \\ |
|
| 82 |
\> bj \>= Y-direction process(or) number - used for bibjflg=1-3 \\ |
\noindent |
| 83 |
\> myThid \>= Current Thread number \\ |
{\bf DIAGNOSTICS\_FILL} |
| 84 |
\end{tabbing} |
(\filelink{pkg/diagnostics/diagnostics\_fill.F}{pkg-diagnostics-diagnostics\_fill.F}): |
| 85 |
|
This is the main user interface routine to the diagnostics package. |
| 86 |
\noindent |
This routine will increment the specified |
| 87 |
{\bf diagnostics\_scale\_fill}: This is a possible alternative routine to |
diagnostic quantity with a field sent through the argument list. |
| 88 |
diagnostics\_fill which performs the same functions and has an additional option |
|
| 89 |
|
\begin{verbatim} |
| 90 |
|
CALL DIAGNOSTICS_FILL( |
| 91 |
|
I inpFld, chardiag, |
| 92 |
|
I kLev, nLevs, bibjFlg, bi, bj, myThid ) |
| 93 |
|
|
| 94 |
|
where: |
| 95 |
|
inpFld = Field to increment diagnostics array |
| 96 |
|
diagName = diagnostic identificator name (8 characters long) |
| 97 |
|
kLev = Integer flag for vertical levels: |
| 98 |
|
> 0 (any integer): WHICH single level to increment in qdiag. |
| 99 |
|
0,-1 to increment "nLevs" levels in qdiag, |
| 100 |
|
0 : fill-in in the same order as the input array |
| 101 |
|
-1: fill-in in reverse order. |
| 102 |
|
nLevs = indicates Number of levels of the input field array |
| 103 |
|
(whether to fill-in all the levels (kLev<1) or just one (kLev>0)) |
| 104 |
|
bibjFlg = Integer flag to indicate instructions for bi bj loop |
| 105 |
|
= 0 indicates that the bi-bj loop must be done here |
| 106 |
|
= 1 indicates that the bi-bj loop is done OUTSIDE |
| 107 |
|
= 2 indicates that the bi-bj loop is done OUTSIDE |
| 108 |
|
AND that we have been sent a local array (with overlap regions) |
| 109 |
|
(local array here means that it has no bi-bj dimensions) |
| 110 |
|
= 3 indicates that the bi-bj loop is done OUTSIDE |
| 111 |
|
AND that we have been sent a local array |
| 112 |
|
AND that the array has no overlap region (interior only) |
| 113 |
|
NOTE - bibjFlg can be NEGATIVE to indicate not to increment counter |
| 114 |
|
bi = X-direction tile number - used for bibjFlg=1-3 |
| 115 |
|
bj = Y-direction tile number - used for bibjFlg=1-3 |
| 116 |
|
myThid = my thread Id number |
| 117 |
|
\end{verbatim} |
| 118 |
|
|
| 119 |
|
\noindent |
| 120 |
|
{\bf DIAGNOSTICS\_SCALE\_FILL} |
| 121 |
|
(\filelink{pkg/diagnostics/diagnostics\_scale\_fill.F}{pkg-diagnostics-diagnostics\_scale\_fill.F}): |
| 122 |
|
This is a possible alternative routine to |
| 123 |
|
DIAGNOSTICS\_FILL which performs the same functions and has an additional option |
| 124 |
to scale the field before filling or raise the field to a power before filling. |
to scale the field before filling or raise the field to a power before filling. |
| 125 |
|
|
| 126 |
|
\begin{verbatim} |
| 127 |
|
CALL DIAGNOSTICS_SCALE_FILL( |
| 128 |
|
I inpFld, scaleFact, power, chardiag, |
| 129 |
|
I kLev, nLevs, bibjFlg, bi, bj, myThid ) |
| 130 |
|
|
| 131 |
|
|
| 132 |
|
where all the arguments are the same as for DIAGNOSTICS_FILL with |
| 133 |
|
the addition of: |
| 134 |
|
scaleFact = Scaling factor to apply to the input field product |
| 135 |
|
power = Integer power to which to raise the input field (before scaling) |
| 136 |
|
\end{verbatim} |
| 137 |
|
|
| 138 |
\noindent |
\noindent |
| 139 |
\begin{tabbing} |
{\bf DIAGNOSTICS\_IS\_ON}: Function call to inquire whether a |
| 140 |
XXXXXXXXX\=XXXXXX\= \kill |
diagnostic is active and can be incremented. Useful when there is a |
| 141 |
\> call diagnostics\_scale\_fill (arrayin, scalefactor, power, chardiag, \\ |
computation that must be done locally before a call to |
| 142 |
\> levflg, nlevs, bibjflg, bi, bj, myThid) \\ |
DIAGNOSTICS\_FILL. The call sequence: |
| 143 |
\\ |
|
| 144 |
where \> All the arguments are the same as for diagnostics\_fill with the addition of: \\ |
\begin{verbatim} |
| 145 |
\> scalefactor \>= Factor to scale field \\ |
flag = DIAGNOSTICS_IS_ON( diagName, myThid ) |
| 146 |
\> power \>= Integer power to which to raise the input field \\ |
|
| 147 |
\end{tabbing} |
where: |
| 148 |
|
diagName = diagnostic identificator name (8 characters long) |
| 149 |
\noindent |
myThid = my thread Id number |
| 150 |
{\bf diagnostics\_is\_on}: Function call to inquire whether a diagnostic is active |
\end{verbatim} |
|
and can be incremented. Useful when there is a computation that must be done locally |
|
|
before a call to diagnostics\_fill. The call sequence: |
|
|
|
|
|
\noindent |
|
|
\begin{tabbing} |
|
|
XXXXXXXXX\=XXXXXX\= \kill |
|
|
\> flag = diagnostics\_is\_on( diagName, myThid ) |
|
|
\\ |
|
|
where \> diagName \>= Character *8 expression for diagnostic \\ |
|
|
\> myThid \>= Current Thread number \\ |
|
|
\end{tabbing} |
|
| 151 |
|
|
| 152 |
\noindent |
\noindent |
| 153 |
{\bf diagnostics\_get\_pointers}: This subroutine retrieves the value of a the diagnostics |
{\bf DIAGNOSTICS\_GET\_POINTERS} |
| 154 |
pointers that other routines require as input - can be useful if the diagnostics common |
(\filelink{pkg/diagnostics/diagnostics\_utils.F}{pkg-diagnostics-diagnostics\_utils.F}): |
| 155 |
|
This subroutine retrieves the value of a the diagnostics pointers |
| 156 |
|
that other routines require as input - can be useful if the diagnostics common |
| 157 |
blocks are not local to a routine. |
blocks are not local to a routine. |
| 158 |
|
|
| 159 |
\noindent |
\begin{verbatim} |
| 160 |
\begin{tabbing} |
CALL DIAGNOSTICS_GET_POINTERS( |
| 161 |
XXXXXXXXX\=XXXXXX\= \kill |
I diagName, listId, |
| 162 |
\> call diagnostics\_get\_pointers( diagName, ipoint, jpoint, myThid ) |
O ndId, ip, |
| 163 |
\\ |
I myThid ) |
| 164 |
where \> diagName \>= Character *8 expression of diagnostic \\ |
|
| 165 |
\> ipoint \>= Pointer into qdiag array - from idiag array in common \\ |
where: |
| 166 |
\> jpoint \>= Pointer into diagnostics menu - from jdiag array in common \\ |
diagName = diagnostic identificator name (8 characters long) |
| 167 |
\> myThid \>= Current Thread number \\ |
listId = list number that specifies the output frequency |
| 168 |
\end{tabbing} |
ndId = diagnostics Id number (in available diagnostics list) |
| 169 |
|
ip = diagnostics pointer to storage array |
| 170 |
\noindent |
myThid = my Thread Id number |
| 171 |
{\bf getdiag}: This subroutine retrieves the value of a model diagnostic. This routine |
\end{verbatim} |
| 172 |
is particulary useful when called from a user output routine, although it can be called |
|
| 173 |
from any routine. This routine returns the time-averaged value of the diagnostic by |
\noindent |
| 174 |
dividing the current accumulated diagnostic value by its corresponding counter. This |
{\bf GETDIAG} |
| 175 |
routine does not change the value of the diagnostic itself, that is, it does not replace |
(\filelink{pkg/diagnostics/diagnostics\_utils.F}{pkg-diagnostics-diagnostics\_utils.F}): |
| 176 |
the diagnostic with its time-average. The calling sequence for this routine is givin by: |
This subroutine retrieves the value of a model diagnostic. |
| 177 |
|
This routine is particularly useful when called from a |
| 178 |
\noindent |
user output routine, although it can be called from any routine. This |
| 179 |
\begin{tabbing} |
routine returns the time-averaged value of the diagnostic by dividing |
| 180 |
XXXXXXXXX\=XXXXXX\= \kill |
the current accumulated diagnostic value by its corresponding counter. |
| 181 |
\> call getdiag (lev, undef, qtmp, ipoint, mate, bi, bj, myThid) \\ |
This routine does not change the value of the diagnostic itself, that |
| 182 |
\\ |
is, it does not replace the diagnostic with its time-average. The |
| 183 |
where \> lev \>= Model Level at which the diagnostic is desired \\ |
calling sequence for this routine is givin by: |
| 184 |
\> undef \>= Fill value to be used when diagnostic is undefined \\ |
|
| 185 |
\> qtmp \>= Time-Averaged Diagnostic Output \\ |
\begin{verbatim} |
| 186 |
\> ipoint \>= Pointer into qdiag array - from idiag array in common \\ |
CALL GETDIAG( |
| 187 |
\> mate \>= Diagnostic mate pointer number \\ |
I levreal, undef, |
| 188 |
\> bi \>= X-direction process(or) number \\ |
O qtmp, |
| 189 |
\> bj \>= Y-direction process(or) number \\ |
I ndId, mate, ip, im, bi, bj, myThid ) |
| 190 |
\> myThid \>= Current Thread number \\ |
|
| 191 |
\end{tabbing} |
where: |
| 192 |
|
lev = Model Level at which the diagnostic is desired |
| 193 |
\noindent |
undef = Fill value to be used when diagnostic is undefined |
| 194 |
{\bf diagnostics\_add2list}: This subroutine enables a diagnostic from the Diagnostic Menu, meaning |
qtmp = Time-Averaged Diagnostic Output |
| 195 |
that space is allocated for the diagnostic and the model routines will increment the |
ndId = diagnostics Id number (in available diagnostics list) |
| 196 |
diagnostic value during execution. This routine is the underlying interface routine |
mate = counter diagnostic number if any ; 0 otherwise |
| 197 |
for defining a new permanent diagnostic in the main model or in a package. The calling sequence is: |
ip = pointer to storage array location for diag. |
| 198 |
|
im = pointer to storage array location for mate |
| 199 |
\noindent |
bi = X-direction tile number |
| 200 |
\begin{tabbing} |
bj = Y-direction tile number |
| 201 |
XXXXXXXXX\=XXXXXX\= \kill |
myThid = my thread Id number |
| 202 |
\> call diagnostics\_add2list( diagNum,diagName, diagCode, \\ |
\end{verbatim} |
| 203 |
\> diagUnits, diagTitle, myThid ) \\ |
|
| 204 |
\\ |
\noindent |
| 205 |
where \> diagNum \>=Diagnostic number - Output from routine \\ |
{\bf DIAGNOSTICS\_CLRDIAG} |
| 206 |
\> diagName \>=character*8 diagnostic name \\ |
(\filelink{pkg/diagnostics/diagnostics\_clear.F}{pkg-diagnostics-diagnostics\_clear.F}): |
| 207 |
\> diagCode \>=character*16 parsing code (see description of gdiag below) \\ |
This subroutine initializes the values of model |
| 208 |
\> diagUnits \>=Diagnostic units (character*16) \\ |
diagnostics to zero, and is particularly useful when called from user |
| 209 |
\> diagTitle \>=Diagnostic title or long name (up to character*80) \\ |
output routines to re-initialize diagnostics during the run. |
| 210 |
\> myThid \>=Current Thread number \\ |
The calling sequence is: |
| 211 |
\end{tabbing} |
|
| 212 |
|
\begin{verbatim} |
| 213 |
\noindent |
CALL DIAGNOSTICS_CLRDIAG ( ipt, nLev, myThid ) |
| 214 |
{\bf clrdiag}: This subroutine initializes the values of model diagnostics to zero, and is |
|
| 215 |
particularly useful when called from user output routines to re-initialize diagnostics |
where: |
| 216 |
during the run. The calling sequence is: |
ipt :: diagnostic pointer to storage array |
| 217 |
|
nLev :: number of levels (in storage array) to reset |
| 218 |
\noindent |
myThid :: my Thread Id number |
| 219 |
\begin{tabbing} |
\end{verbatim} |
| 220 |
XXXXXXXXX\=XXXXXX\= \kill |
|
| 221 |
\> call diagnostics\_clrdiag (jpoint, ipoint, myThid) \\ |
\noindent |
| 222 |
\\ |
The diagnostics are computed at various times and places within the |
| 223 |
where \> jpoint \>= Diagnostic number from menu - from jdiag array \\ |
GCM. Because MITgcm may employ a staggered grid, diagnostics may be |
| 224 |
ipoint \>= Pointer number into qdiag array - from idiag array \\ |
computed at grid box centers, corners, or edges, and at the middle or |
| 225 |
\> myThid \>=Current Thread number \\ |
edge in the vertical. Some diagnostics are scalars, while others are |
| 226 |
\end{tabbing} |
components of vectors. An internal array is defined which contains |
| 227 |
|
information concerning various grid attributes of each diagnostic. The |
| 228 |
\noindent |
GDIAG array (in common block {\tt diagnostics} in file {\tt |
| 229 |
The diagnostics are computed at various times and places within the GCM. Because the |
DIAGNOSTICS.h}) is internally defined as a character*10 variable, and |
| 230 |
MIT GCM may employ a staggered grid, diagnostics may be computed at grid box centers, |
is equivalenced to a character*1 "parse" array in output in order to |
| 231 |
corners, or edges, and at the middle or edge in the vertical. Some diagnostics are scalars, |
extract the grid-attribute information. The GDIAG array is described |
| 232 |
while others are components of vectors. An internal array is defined which contains |
in Table \ref{tab:diagnostics:gdiag.tabl}. |
|
information concerning various grid attributes of each diagnostic. The GDIAG |
|
|
array (in common block \\diagnostics in file DIAGNOSTICS.h) is internally defined as a |
|
|
character*8 variable, and is equivalenced to a character*1 "parse" array in output in |
|
|
order to extract the grid-attribute information. The GDIAG array is described in |
|
|
Table \ref{tab:diagnostics:gdiag.tabl}. |
|
| 233 |
|
|
| 234 |
\begin{table} |
\begin{table} |
| 235 |
\caption{Diagnostic Parsing Array} |
\caption{Diagnostic Parsing Array} |
| 242 |
\hline |
\hline |
| 243 |
Array & Value & Description \\ |
Array & Value & Description \\ |
| 244 |
\hline |
\hline |
| 245 |
parse(1) & $\rightarrow$ S & Scalar Diagnostic \\ |
parse(1) & $\rightarrow$ S & Scalar Diagnostic \\ |
| 246 |
& $\rightarrow$ U & U-vector component Diagnostic \\ |
& $\rightarrow$ U & U-vector component Diagnostic \\ |
| 247 |
& $\rightarrow$ V & V-vector component Diagnostic \\ \hline |
& $\rightarrow$ V & V-vector component Diagnostic \\ \hline |
| 248 |
parse(2) & $\rightarrow$ U & C-Grid U-Point \\ |
parse(2) & $\rightarrow$ U & C-Grid U-Point \\ |
| 249 |
& $\rightarrow$ V & C-Grid V-Point \\ |
& $\rightarrow$ V & C-Grid V-Point \\ |
| 250 |
& $\rightarrow$ M & C-Grid Mass Point \\ |
& $\rightarrow$ M & C-Grid Mass Point \\ |
| 251 |
& $\rightarrow$ Z & C-Grid Vorticity (Corner) Point \\ \hline |
& $\rightarrow$ Z & C-Grid Vorticity (Corner) Point \\ \hline |
| 252 |
parse(3) & $\rightarrow$ R & Not Currently in Use \\ \hline |
parse(3) & $\rightarrow$ & Used for Level Integrated output: cumulate levels \\ |
| 253 |
parse(4) & $\rightarrow$ P & Positive Definite Diagnostic \\ \hline |
& $\rightarrow$ r & same but cumulate product by model level thickness \\ |
| 254 |
parse(5) & $\rightarrow$ C & Counter Diagnostic \\ |
& $\rightarrow$ R & same but cumulate product by hFac \& level thickness \\ \hline |
| 255 |
& $\rightarrow$ D & Disabled Diagnostic for output \\ \hline |
parse(4) & $\rightarrow$ P & Positive Definite Diagnostic \\ \hline |
| 256 |
parse(6-8) & $\rightarrow$ C & 3-digit integer corresponding to \\ |
parse(5) & $\rightarrow$ C & with Counter array \\ |
| 257 |
& & vector or counter component mate \\ \hline |
& $\rightarrow$ D & Disabled Diagnostic for output \\ \hline |
| 258 |
|
parse(6-8)& & retired, formerly: 3-digit mate number \\ \hline |
| 259 |
|
parse(9) & $\rightarrow$ U & model-level plus 1/2 \\ |
| 260 |
|
& $\rightarrow$ M & model-level middle \\ |
| 261 |
|
& $\rightarrow$ L & model-level minus 1/2 \\ \hline |
| 262 |
|
parse(10) & $\rightarrow$ 0 & levels = 0 \\ |
| 263 |
|
& $\rightarrow$ 1 & levels = 1 \\ |
| 264 |
|
& $\rightarrow$ R & levels = Nr \\ |
| 265 |
|
& $\rightarrow$ L & levels = MAX(Nr,NrPhys) \\ |
| 266 |
|
& $\rightarrow$ M & levels = MAX(Nr,NrPhys) - 1 \\ |
| 267 |
|
& $\rightarrow$ G & levels = Ground\_level Number \\ |
| 268 |
|
& $\rightarrow$ I & levels = sea-Ice\_level Number \\ |
| 269 |
|
& $\rightarrow$ X & free levels option (need to be set explicitly)\\ \hline |
| 270 |
\end{tabular} |
\end{tabular} |
| 271 |
\addcontentsline{lot}{section}{Table 3: Diagnostic Parsing Array} |
\addcontentsline{lot}{section}{Table 3: Diagnostic Parsing Array} |
| 272 |
\end{center} |
\end{center} |
| 275 |
|
|
| 276 |
\noindent |
\noindent |
| 277 |
As an example, consider a diagnostic whose associated GDIAG parameter is equal |
As an example, consider a diagnostic whose associated GDIAG parameter is equal |
| 278 |
to ``UU 002''. From GDIAG we can determine that this diagnostic is a |
to ``UUR\hspace{5mm}MR''. From GDIAG we can determine that this diagnostic is a |
| 279 |
U-vector component located at the C-grid U-point. |
U-vector component located at the C-grid U-point, model mid-level (M) |
| 280 |
Its corresponding V-component diagnostic is located in Diagnostic \# 002. |
with Nr levels (last R). |
| 281 |
|
|
| 282 |
\noindent |
\noindent |
| 283 |
In this way, each Diagnostic in the model has its attributes (ie. vector or scalar, |
In this way, each Diagnostic in the model has its attributes (ie. vector or scalar, |
| 287 |
In this way the User has flexibility in determining the type of gridded data which |
In this way the User has flexibility in determining the type of gridded data which |
| 288 |
is output. |
is output. |
| 289 |
|
|
| 290 |
\subsubsection{Usage Notes} |
\subsection{Usage Notes} |
| 291 |
\label{sec:diagnostics:usersguide} |
\label{sec:diagnostics:usersguide} |
| 292 |
|
|
| 293 |
\noindent |
\noindent |
| 294 |
To use the diagnostics package, other than enabling it in packages.conf |
To use the diagnostics package, other than enabling it in {\tt packages.conf} |
| 295 |
and turning the usediagnostics flag in data.pkg to .TRUE., there are two |
and turning the {\tt useDiagnostics} flag in {\tt data.pkg} to .TRUE., there are two |
| 296 |
further steps the user must take to enable the diagnostics package for |
further steps the user must take to enable the diagnostics package for |
| 297 |
output of quantities that are already defined in the GCM under an experiment's |
output of quantities that are already defined in the GCM under an experiment's |
| 298 |
configuration of packages. A namelist must be supplied in the run directory |
configuration of packages. |
| 299 |
called data.diagnostics, and the file DIAGNOSTICS\_SIZE.h must be included in the |
A parameter file {\tt data.diagnostics} must be supplied in the run directory, |
| 300 |
|
and the file DIAGNOSTICS\_SIZE.h must be included in the |
| 301 |
code directory. The steps for defining a new (permanent or experiment-specific |
code directory. The steps for defining a new (permanent or experiment-specific |
| 302 |
temporary) diagnostic quantity will be outlined later. |
temporary) diagnostic quantity will be outlined later. |
| 303 |
|
|
| 304 |
\noindent The namelist will activate a user-defined list of diagnostics quantities |
\noindent The namelist in parameter file {\tt data.diagnostics} will activate |
| 305 |
to be computed, specify the frequency and type of output, the number of levels, and |
a user-defined list of diagnostics quantities to be computed, |
| 306 |
the name of all the separate output files. A sample data.diagnostics namelist file: |
specify the frequency and type of output, the number of levels, and |
| 307 |
|
the name of all the separate output files. |
| 308 |
\noindent |
A sample {\tt data.diagnostics} namelist file: |
| 309 |
$\#$ Diagnostic Package Choices \\ |
|
| 310 |
$\&$diagnostics\_list \\ |
\begin{verbatim} |
| 311 |
frequency(1) = 86400., \ \\ |
# Diagnostic Package Choices |
| 312 |
levels(1,1) = 1., \ \\ |
#-------------------- |
| 313 |
fields(1,1) = 'RSURF ', \ \\ |
# dumpAtLast (logical): always write output at the end of simulation (default=F) |
| 314 |
filename(1) = 'surface', \ \\ |
# diag_mnc (logical): write to NetCDF files (default=useMNC) |
| 315 |
frequency(2) = 86400., \ \\ |
#--for each output-stream: |
| 316 |
levels(1,2) = 1.,2.,3.,4.,5., \ \\ |
# fileName(n) : prefix of the output file name (max 80c long) for outp.stream n |
| 317 |
fields(1,2) = 'UVEL ','VVEL ', \ \\ |
# frequency(n):< 0 : write snap-shot output every |frequency| seconds |
| 318 |
filename(2) = 'diagout1', \ \\ |
# > 0 : write time-average output every frequency seconds |
| 319 |
frequency(3) = 3600., \ \\ |
# timePhase(n) : write at time = timePhase + multiple of |frequency| |
| 320 |
fields(1,3) = 'UVEL ','VVEL ','PRESSURE', \ \\ |
# averagingFreq : frequency (in s) for periodic averaging interval |
| 321 |
filename(3) = 'diagout2', \ \\ |
# averagingPhase : phase (in s) for periodic averaging interval |
| 322 |
fileflags(3) = ' P1 ', \ \\ |
# repeatCycle : number of averaging intervals in 1 cycle |
| 323 |
$\&$end \ \\ |
# levels(:,n) : list of levels to write to file (Notes: declared as REAL) |
| 324 |
|
# when this entry is missing, select all common levels of this list |
| 325 |
\noindent |
# fields(:,n) : list of selected diagnostics fields (8.c) in outp.stream n |
| 326 |
In this example, there are two output files that will be generated |
# (see "available_diagnostics.log" file for the full list of diags) |
| 327 |
for each tile and for each output time. The first set of output files |
# missing_value(n) : missing value for real-type fields in output file "n" |
| 328 |
has the prefix diagout1, does time averaging every 86400. seconds, |
# fileFlags(n) : specific code (8c string) for output file "n" |
| 329 |
(frequency is 86400.), and will write fields which are multiple-level |
#-------------------- |
| 330 |
fields at output levels 1-5. The names of diagnostics quantities are |
&DIAGNOSTICS_LIST |
| 331 |
UVEL and VVEL. The second set of output files |
fields(1:2,1) = 'UVEL ','VVEL ', |
| 332 |
has the prefix diagout2, does time averaging every 3600. seconds, |
levels(1:5,1) = 1.,2.,3.,4.,5., |
| 333 |
includes fields which are multiple-level fields, levels output are 1-5, |
filename(1) = 'diagout1', |
| 334 |
and the names of diagnostics quantities are THETA and SALT. |
frequency(1) = 86400., |
| 335 |
|
fields(1:3,2) = 'THETA ','SALT ', |
| 336 |
\noindent |
filename(2) = 'diagout2', |
| 337 |
The user must assure that enough computer memory is allocated for the diagnostics |
fileflags(2) = ' P1 ', |
| 338 |
and the output streams selected for a particular experiment. This is acomplished by |
frequency(2) = 3600., |
| 339 |
modifying the file DIAGNOSTICS\_SIZE.h and including it in the experiment code directory. |
& |
| 340 |
The parameters that should be checked are called numdiags, numlists, numperlist, and |
|
| 341 |
diagSt\_size. |
#-------------------- |
| 342 |
|
# Parameter for Diagnostics of per level statistics: |
| 343 |
|
#-------------------- |
| 344 |
|
# diagSt_mnc (logical): write stat-diags to NetCDF files (default=diag_mnc) |
| 345 |
|
# diagSt_regMaskFile : file containing the region-mask to read-in |
| 346 |
|
# nSetRegMskFile : number of region-mask sets within the region-mask file |
| 347 |
|
# set_regMask(i) : region-mask set-index that identifies the region "i" |
| 348 |
|
# val_regMask(i) : region "i" identifier value in the region mask |
| 349 |
|
#--for each output-stream: |
| 350 |
|
# stat_fName(n) : prefix of the output file name (max 80c long) for outp.stream n |
| 351 |
|
# stat_freq(n):< 0 : write snap-shot output every |stat_freq| seconds |
| 352 |
|
# > 0 : write time-average output every stat_freq seconds |
| 353 |
|
# stat_phase(n) : write at time = stat_phase + multiple of |stat_freq| |
| 354 |
|
# stat_region(:,n) : list of "regions" (default: 1 region only=global) |
| 355 |
|
# stat_fields(:,n) : list of selected diagnostics fields (8.c) in outp.stream n |
| 356 |
|
# (see "available_diagnostics.log" file for the full list of diags) |
| 357 |
|
#-------------------- |
| 358 |
|
&DIAG_STATIS_PARMS |
| 359 |
|
& |
| 360 |
|
\end{verbatim} |
| 361 |
|
|
| 362 |
|
\noindent |
| 363 |
|
In this example, there are two output files that will be generated for |
| 364 |
|
each tile and for each output time. The first set of output files has |
| 365 |
|
the prefix diagout1, does time averaging every 86400. seconds, |
| 366 |
|
(frequency is 86400.), and will write fields which are multiple-level |
| 367 |
|
fields at output levels 1-5. The names of diagnostics quantities are |
| 368 |
|
UVEL and VVEL. The second set of output files has the prefix |
| 369 |
|
diagout2, does time averaging every 3600. seconds, includes fields |
| 370 |
|
with all levels, and the names of diagnostics quantities are THETA and SALT. |
| 371 |
|
|
| 372 |
|
\noindent |
| 373 |
|
The user must assure that enough computer memory is allocated for the |
| 374 |
|
diagnostics and the output streams selected for a particular |
| 375 |
|
experiment. This is accomplished by modifying the file |
| 376 |
|
DIAGNOSTICS\_SIZE.h and including it in the experiment code directory. |
| 377 |
|
The parameters that should be checked are called numDiags, numLists, |
| 378 |
|
numperList, and diagSt\_size. |
| 379 |
|
|
| 380 |
\noindent numdiags (and diagSt\_size): \\ |
\noindent numDiags (and diagSt\_size): \\ |
| 381 |
\noindent All GCM diagnostic quantities are stored in the single diagnostic array QDIAG |
\noindent All GCM diagnostic quantities are stored in the single diagnostic array QDIAG |
| 382 |
which is located in the file \\ \filelink{pkg/diagnostics/DIAGNOSTICS.h}{pkg-diagnostics-DIAGNOSTICS.h}.\\ |
which is located in the file |
| 383 |
|
\filelink{pkg/diagnostics/DIAGNOSTICS.h}{pkg-diagnostics-DIAGNOSTICS.h} |
| 384 |
and has the form:\\ |
and has the form:\\ |
| 385 |
common /diagnostics/ qdiag(1-Olx,sNx+Olx,1-Olx,sNx+Olx,numdiags,Nsx,Nsy) \\ |
\begin{verbatim} |
| 386 |
\noindent |
_RL qdiag(1-Olx,sNx+Olx,1-Olx,sNx+Olx,numDiags,nSx,nSy) |
| 387 |
The first two-dimensions of qdiag correspond to the horizontal dimension of a given diagnostic, |
_RL qSdiag(0:nStats,0:nRegions,diagSt_size,nSx,nSy) |
| 388 |
and the third dimension of qdiag is used to identify diagnostic fields and levels combined. In |
COMMON / DIAG_STORE_R / qdiag, qSdiag |
| 389 |
order to minimize the memory requirement of the model for diagnostics, the default GCM |
\end{verbatim} |
| 390 |
executable is compiled with room for only one horizontal diagnostic array, or with |
\noindent |
| 391 |
numdiags set to Nr. In order for the User to enable more than 1 three-dimensional diagnostic, |
The first two-dimensions of qdiag correspond to the horizontal |
| 392 |
the size of the diagnostics common must be expanded to accomodate the desired diagnostics. |
dimension of a given diagnostic, and the third dimension of qdiag is |
| 393 |
This can be accomplished by manually changing the parameter numdiags in the |
used to identify diagnostic fields and levels combined. In order to |
| 394 |
file \filelink{pkg/diagnostics/DIAGNOSTICS\_SIZE.h}{pkg-diagnostics-DIAGNOSTICS\_SIZE.h}. |
minimize the memory requirement of the model for diagnostics, the |
| 395 |
numdiags should be set greater than or equal to the sum of all the diagnostics activated |
default GCM executable is compiled with room for only one horizontal |
| 396 |
for output each multiplied by the number of levels defined for that diagnostic quantity. |
diagnostic array, or with numDiags set to Nr. In order for the User to |
| 397 |
For the above example, there are 4 multiple level fields, which the diagnostics menu |
enable more than 1 three-dimensional diagnostic, the size of the |
| 398 |
(see below) indicates are defined at the GCM vertical resolution, Nr. The value of |
diagnostics common must be expanded to accommodate the desired |
| 399 |
numdiag in DIAGNOSTICS\_SIZE.h would therefore be equal to 4*Nr, or, say 40 if $Nr=10$. |
diagnostics. This can be accomplished by manually changing the |
| 400 |
|
parameter numDiags in the file |
| 401 |
\noindent numlists and numperlist: \\ |
\filelink{pkg/diagnostics/DIAGNOSTICS\_SIZE.h}{pkg-diagnostics-DIAGNOSTICS\_SIZE.h}. |
| 402 |
\noindent The parameter numlists must be set greater than or equal to the number of |
numDiags should be set greater than or equal to the sum of all the |
| 403 |
separate output streams that the user specifies in the namelist file data.diagnostics. |
diagnostics activated for output each multiplied by the number of |
| 404 |
The parameter numperlist corresponds to the number of diagnostics requested in each |
levels defined for that diagnostic quantity. For the above example, |
| 405 |
output stream. |
there are 4 multiple level fields, which the diagnostics menu (see |
| 406 |
|
below) indicates are defined at the GCM vertical resolution, Nr. The |
| 407 |
\noindent |
value of numDiags in DIAGNOSTICS\_SIZE.h would therefore be equal to |
| 408 |
In order to define and include as part of the diagnostic output any field |
4*Nr, or, say 40 if $Nr=10$. |
| 409 |
that is desired for a particular experiment, two steps must be taken. The |
|
| 410 |
first is to enable the ``User Diagnostic'' in data.diagnostics. This is |
\noindent numLists and numperList: \\ |
| 411 |
accomplished by adding one of the ``User Diagnostic'' field names (UDIAG1 through |
\noindent The parameter numLists must be set greater than or equal to |
| 412 |
UDIAG10, for multi-level fields, or SDIAG1 through SDIAG10 for single level |
the number of separate output streams that the user specifies in the |
| 413 |
fields) to the data.diagnostics namelist in one of the output streams. These |
namelist file data.diagnostics. The parameter numperList corresponds |
| 414 |
fields are listed in the diagnostics menu. The second step is to |
to the maximum number of diagnostics requested per output streams. |
| 415 |
add a call to diagnostics\_fill from the subroutine in which the quantity |
|
| 416 |
desired for diagnostic output is computed. |
\noindent |
| 417 |
|
In order to define and include as part of the diagnostic output any |
| 418 |
\noindent |
field that is desired for a particular experiment, two steps must be |
| 419 |
In order to add a new diagnostic to the permanent set of diagnostics that the |
taken. The first is to enable the ``User Diagnostic'' in |
| 420 |
main model or any package contains as part of its diagnostics menu, the subroutine |
{\tt data.diagnostics}. This is accomplished by adding one of the ``User |
| 421 |
diagnostics\_add2list should be called during the initialization phase of the |
Diagnostic'' field names (UDIAG1 through UDIAG10, for multi-level |
| 422 |
main model or package. For the main model, the call should be made from |
fields, or SDIAG1 through SDIAG10 for single level fields) to the |
| 423 |
subroutine diagnostics\_main\_init, and for a package, the call should probably |
data.diagnostics namelist in one of the output streams. These fields |
| 424 |
be made from somewhere in the packages\_init\_fixed sequence (probaby from inside |
are listed in the diagnostics menu. The second step is to add a call |
| 425 |
the particular package's init\_fixed routine). A typical code sequence to set the |
to DIAGNOSTICS\_FILL from the subroutine in which the quantity desired |
| 426 |
input arguments to diagnostics\_add2list would look like: |
for diagnostic output is computed. |
| 427 |
|
|
| 428 |
\noindent |
\noindent |
| 429 |
\begin{tabbing} |
In order to add a new diagnostic to the permanent set of diagnostics |
| 430 |
XXXXXXXXX\=XXXXXX\= \kill |
that the main model or any package contains as part of its diagnostics |
| 431 |
\> diagName = 'THETA ' \\ |
menu, the subroutine DIAGNOSTICS\_ADDTOLIST should be called during the |
| 432 |
\> diagTitle = 'Potential Temperature (degC,K)' \\ |
initialization phase of the main model or package. For the main model, |
| 433 |
\> diagUnits = 'Degrees K ' \\ |
the call should be made from subroutine DIAGNOSTICS\_MAIN\_INIT, and |
| 434 |
\> diagCode = 'SM MR ' \\ |
for a package, the call should probably be made from |
| 435 |
\> CALL DIAGNOSTICS\_ADD2LIST( diagNum, \\ |
%somewhere in the PACKAGES\_INIT\_FIXED sequence (probably |
| 436 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
from inside the particular package's init\_fixed routine. |
| 437 |
\\ |
A typical code sequence to set the |
| 438 |
\end{tabbing} |
input arguments to DIAGNOSTICS\_ADDTOLIST would look like: |
| 439 |
|
|
| 440 |
\noindent If the new diagnostic quantity is associated with either a vector |
\begin{verbatim} |
| 441 |
pair or a diagnostic counter, the diagCode argument must be filled with the |
diagName = 'RHOAnoma' |
| 442 |
proper index for the ``mate''. The output argument from diagnostics\_add2list |
diagTitle = 'Density Anomaly (=Rho-rhoConst)' |
| 443 |
that is called diagNum here contains a running total of the number of diagnostics |
diagUnits = 'kg/m^3 ' |
| 444 |
defined in the code up to any point during the run. The sequence number for the |
diagCode = 'SMR MR ' |
| 445 |
next two diagnostics defined (the two components of the vector pair, for instance) |
CALL DIAGNOSTICS\_ADDTOLIST( diagNum, |
| 446 |
will be diagNum+1 and diagNum+2. The definition of the first component of the vector |
I diagName, diagCode, diagUnits, diagTitle, 0, myThid ) |
| 447 |
pair must fill the ``mate'' segment of the diagCode as diagnostic number diagNum+2. |
\end{verbatim} |
| 448 |
Since the subroutine increments diagNum, the definition of the second component of |
|
| 449 |
the vector fills the ``mate'' part of diagCode with diagNum. A code sequence for |
\noindent If the new diagnostic quantity is associated with either a |
| 450 |
this case would look like: |
vector pair or a diagnostic counter, the diagMate argument must be |
| 451 |
|
provided with the proper index corresponding to the ``mate''. |
| 452 |
\noindent |
The output argument from DIAGNOSTICS\_ADDTOLIST that is called diagNum here |
| 453 |
\begin{tabbing} |
contains a running total of the number of diagnostics defined in the code up to |
| 454 |
XXXXXXXXX\=XXXXXX\= \kill |
any point during the run. The sequence number for the next two |
| 455 |
\> diagName = 'UVEL ' \\ |
diagnostics defined (the two components of the vector pair, for |
| 456 |
\> diagTitle = 'Zonal Velocity ' \\ |
instance) will be diagNum+1 and diagNum+2. The definition of the first |
| 457 |
\> diagUnits = 'm / sec ' \\ |
component of the vector pair must fill the ``mate'' segment of the |
| 458 |
\> diagCode = 'SM MR ' \\ |
diagCode as diagnostic number diagNum+2. Since the subroutine |
| 459 |
\> write(diagCode,'(A,I3.3,A)') 'VV ', diagNum+2 ,'MR ' \\ |
increments diagNum, the definition of the second component of the |
| 460 |
\> call diagnostics\_add2list( diagNum, \\ |
vector fills the ``mate'' part of diagCode with diagNum. A code |
| 461 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
sequence for this case would look like: |
| 462 |
\> diagName = 'VVEL ' \\ |
|
| 463 |
\> diagTitle = 'Meridional Velocity ' \\ |
\begin{verbatim} |
| 464 |
\> diagUnits = 'm / sec ' \\ |
diagName = 'UVEL ' |
| 465 |
\> diagCode = 'SM MR ' \\ |
diagTitle = 'Zonal Component of Velocity (m/s)' |
| 466 |
\> write(diagCode,'(A,I3.3,A)') 'VV ', diagNum ,'MR ' \\ |
diagUnits = 'm/s ' |
| 467 |
\> call diagnostics\_add2list( diagNum, \\ |
diagCode = 'UUR MR ' |
| 468 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
diagMate = diagNum + 2 |
| 469 |
\\ |
CALL DIAGNOSTICS_ADDTOLIST( diagNum, |
| 470 |
\end{tabbing} |
I diagName, diagCode, diagUnits, diagTitle, diagMate, myThid ) |
| 471 |
|
|
| 472 |
|
diagName = 'VVEL ' |
| 473 |
|
diagTitle = 'Meridional Component of Velocity (m/s)' |
| 474 |
|
diagUnits = 'm/s ' |
| 475 |
|
diagCode = 'VVR MR ' |
| 476 |
|
diagMate = diagNum |
| 477 |
|
CALL DIAGNOSTICS_ADDTOLIST( diagNum, |
| 478 |
|
I diagName, diagCode, diagUnits, diagTitle, diagMate, myThid ) |
| 479 |
|
\end{verbatim} |
| 480 |
|
|
| 481 |
\input{part7/diagnostics-menu.tex} |
\input{s_outp_pkgs/text/diagnostics-menu.tex} |
| 482 |
|
|
| 483 |
\newpage |
\newpage |
| 484 |
\noindent For a list of the diagnostic fields available in the |
\noindent For a list of the diagnostic fields available in the |
| 485 |
different MITgcm packages, follow the link to the diagnostics menu |
different MITgcm packages, follow the link to the diagnostics menu |
| 486 |
in the manual section describing the package: |
in the manual section describing the package: |
| 487 |
|
|
| 488 |
\filelink{part6/fizhi-diagnostics-menu.tex}{pkg-fizhi-fizhi-diagnostics-menu.tex} |
\begin{itemize} |
| 489 |
|
\item aim: \ref{sec:pkg:aim:diagnostics} |
| 490 |
|
\item exf: \ref{sec:pkg:exf:diagnostics} |
| 491 |
|
\item gchem: \ref{sec:pkg:gchem:diagnostics} |
| 492 |
|
\item generic\_advdiff: \ref{sec:pkg:gad:diagnostics} |
| 493 |
|
\item gridalt: \ref{sec:pkg:gridalt:diagnostics} |
| 494 |
|
\item gmredi: \ref{sec:pkg:gmredi:diagnostics} |
| 495 |
|
\item fizhi: \ref{sec:pkg:fizhi:diagnostics} |
| 496 |
|
\item kpp: \ref{sec:pkg:kpp:diagnostics} |
| 497 |
|
\item land: \ref{sec:pkg:land:diagnostics} |
| 498 |
|
\item mom\_common: \ref{sec:pkg:mom_common:diagnostics} |
| 499 |
|
\item obcs: \ref{sec:pkg:obcs:diagnostics} |
| 500 |
|
\item thsice: \ref{sec:pkg:thsice:diagnostics} |
| 501 |
|
\item shap\_filt: \ref{sec:pkg:shap_filt:diagnostics} |
| 502 |
|
\item ptracers: \ref{sec:pkg:ptracers:diagnostics} |
| 503 |
|
\end{itemize} |
| 504 |
|
|
| 505 |
\subsubsection{Dos and Donts} |
\subsection{Dos and Donts} |
| 506 |
|
|
| 507 |
\subsubsection{Diagnostics Reference} |
\subsection{Diagnostics Reference} |
| 508 |
|
|
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch