| 1 |
\subsection{Diagnostics--A Flexible Infrastructure} |
| 2 |
\label{sec:pkg:diagnostics} |
| 3 |
\begin{rawhtml} |
| 4 |
<!-- CMIREDIR:package_diagnostics: --> |
| 5 |
\end{rawhtml} |
| 6 |
|
| 7 |
\subsubsection{Introduction} |
| 8 |
|
| 9 |
\noindent |
| 10 |
This section of the documentation describes the Diagnostics package available within |
| 11 |
the GCM. A large selection of model diagnostics is available for output. |
| 12 |
In addition to the diagnostic quantities pre-defined in the GCM, there exists |
| 13 |
the option, in any experiment, to define a new diagnostic quantity and include it |
| 14 |
as part of the diagnostic output with the addition of a single subroutine call in the |
| 15 |
routine where the field is computed. As a matter of philosophy, no diagnostic is enabled |
| 16 |
as default, thus each user must specify the exact diagnostic information required for an |
| 17 |
experiment. This is accomplished by enabling the specific diagnostic of interest cataloged |
| 18 |
in the Diagnostic Menu (see Section \ref{sec:diagnostics:menu}). Instructions for enabling |
| 19 |
diagnostic output and defining new diagnostic quantities are found in Section |
| 20 |
\ref{sec:diagnostics:usersguide} of this document. |
| 21 |
|
| 22 |
\noindent |
| 23 |
The Diagnostic Menu in this section of the manual is a listing of diagnostic quantities available |
| 24 |
within the main (dynamics) part of the GCM. Additional diagnostic quantities, defined within the |
| 25 |
different GCM packages, are available and are listed in the diagnostic menu subsection of |
| 26 |
the manual section associated with each relevant package. Once a diagnostic is enabled, the |
| 27 |
GCM will continually increment an array specifically allocated for that diagnostic whenever the |
| 28 |
appropriate quantity is computed. A counter is defined which records how many times each diagnostic |
| 29 |
quantity has been incremented. Several special diagnostics are included in the menu. Quantities |
| 30 |
refered to as ``Counter Diagnostics'', are defined for selected diagnostics which record the |
| 31 |
frequency at which a diagnostic is incremented separately for each model grid location. |
| 32 |
Quantitied refered to as ``User Diagnostics'' are included in the menu to facilitate |
| 33 |
defining new diagnostics for a particular experiment. |
| 34 |
|
| 35 |
\subsubsection{Equations} |
| 36 |
Not relevant. |
| 37 |
|
| 38 |
\subsubsection{Key Subroutines and Parameters} |
| 39 |
\label{sec:diagnostics:diagover} |
| 40 |
|
| 41 |
\noindent |
| 42 |
There are several utilities within the GCM available to users to enable, disable, |
| 43 |
clear, write and retrieve model diagnostics, and may be called from any routine. |
| 44 |
The available utilities and the CALL sequences are listed below. |
| 45 |
|
| 46 |
\noindent |
| 47 |
{\bf diagnostics\_fill}: This is the main user interface routine to the diagnostics |
| 48 |
package. This routine will increment the specified diagnostic quantity with a field |
| 49 |
sent through the argument list. |
| 50 |
|
| 51 |
\noindent |
| 52 |
\begin{tabbing} |
| 53 |
XXXXXXXXX\=XXXXXX\= \kill |
| 54 |
\> call diagnostics\_fill (arrayin, chardiag, levflg, nlevs, \\ |
| 55 |
\> bibjflg, bi, bj, myThid) \\ |
| 56 |
\\ |
| 57 |
where \> arrayin \>= Field to increment diagnostics array \\ |
| 58 |
\> chardiag \>= Character *8 expression for diag to fill \\ |
| 59 |
\> levflg \>= Integer flag for vertical levels: \\ |
| 60 |
\> \>= 0 indicates multiple (nlevs) levels incremented \\ |
| 61 |
\> \>= -1 indicates multiple (nlevs) levels incremented, \\ |
| 62 |
\> \> but in reverse vertical order \\ |
| 63 |
\> \> positive integer - WHICH single level to increment. \\ |
| 64 |
\> nlevs \>= indicates Number of levels to be filled (1 if levflg gt 0) \\ |
| 65 |
\> bibjflg \>= Integer flag to indicate instructions for bi bj loop \\ |
| 66 |
\> \>= 0 indicates that the bi-bj loop must be done here \\ |
| 67 |
\> \>= 1 indicates that the bi-bj loop is done OUTSIDE \\ |
| 68 |
\> \>= 2 indicates that the bi-bj loop is done OUTSIDE \\ |
| 69 |
\> \> AND that we have been sent a local array \\ |
| 70 |
\> \> AND that the array has the shadow regions \\ |
| 71 |
\> \>= 3 indicates that the bi-bj loop is done OUTSIDE \\ |
| 72 |
\> \> AND that we have been sent a local array \\ |
| 73 |
\> \> AND that the array has no shadow regions \\ |
| 74 |
\> bi \>= X-direction process(or) number - used for bibjflg=1-3 \\ |
| 75 |
\> bj \>= Y-direction process(or) number - used for bibjflg=1-3 \\ |
| 76 |
\> myThid \>= Current Thread number \\ |
| 77 |
\end{tabbing} |
| 78 |
|
| 79 |
\noindent |
| 80 |
{\bf diagnostics\_scale\_fill}: This is a possible alternative routine to |
| 81 |
diagnostics\_fill which performs the same functions and has an additional option |
| 82 |
to scale the field before filling or raise the field to a power before filling. |
| 83 |
|
| 84 |
\noindent |
| 85 |
\begin{tabbing} |
| 86 |
XXXXXXXXX\=XXXXXX\= \kill |
| 87 |
\> call diagnostics\_scale\_fill (arrayin, scalefactor, power, chardiag, \\ |
| 88 |
\> levflg, nlevs, bibjflg, bi, bj, myThid) \\ |
| 89 |
\\ |
| 90 |
where \> All the arguments are the same as for diagnostics\_fill with the addition of: \\ |
| 91 |
\> scalefactor \>= Factor to scale field \\ |
| 92 |
\> power \>= Integer power to which to raise the input field \\ |
| 93 |
\end{tabbing} |
| 94 |
|
| 95 |
\noindent |
| 96 |
{\bf diagnostics\_is\_on}: Function call to inquire whether a diagnostic is active |
| 97 |
and can be incremented. Useful when there is a computation that must be done locally |
| 98 |
before a call to diagnostics\_fill. The call sequence: |
| 99 |
|
| 100 |
\noindent |
| 101 |
\begin{tabbing} |
| 102 |
XXXXXXXXX\=XXXXXX\= \kill |
| 103 |
\> flag = diagnostics\_is\_on( diagName, myThid ) |
| 104 |
\\ |
| 105 |
where \> diagName \>= Character *8 expression for diagnostic \\ |
| 106 |
\> myThid \>= Current Thread number \\ |
| 107 |
\end{tabbing} |
| 108 |
|
| 109 |
\noindent |
| 110 |
{\bf diagnostics\_get\_pointers}: This subroutine retrieves the value of a the diagnostics |
| 111 |
pointers that other routines require as input - can be useful if the diagnostics common |
| 112 |
blocks are not local to a routine. |
| 113 |
|
| 114 |
\noindent |
| 115 |
\begin{tabbing} |
| 116 |
XXXXXXXXX\=XXXXXX\= \kill |
| 117 |
\> call diagnostics\_get\_pointers( diagName, ipoint, jpoint, myThid ) |
| 118 |
\\ |
| 119 |
where \> diagName \>= Character *8 expression of diagnostic \\ |
| 120 |
\> ipoint \>= Pointer into qdiag array - from idiag array in common \\ |
| 121 |
\> jpoint \>= Pointer into diagnostics menu - from jdiag array in common \\ |
| 122 |
\> myThid \>= Current Thread number \\ |
| 123 |
\end{tabbing} |
| 124 |
|
| 125 |
\noindent |
| 126 |
{\bf getdiag}: This subroutine retrieves the value of a model diagnostic. This routine |
| 127 |
is particulary useful when called from a user output routine, although it can be called |
| 128 |
from any routine. This routine returns the time-averaged value of the diagnostic by |
| 129 |
dividing the current accumulated diagnostic value by its corresponding counter. This |
| 130 |
routine does not change the value of the diagnostic itself, that is, it does not replace |
| 131 |
the diagnostic with its time-average. The calling sequence for this routine is givin by: |
| 132 |
|
| 133 |
\noindent |
| 134 |
\begin{tabbing} |
| 135 |
XXXXXXXXX\=XXXXXX\= \kill |
| 136 |
\> call getdiag (lev, undef, qtmp, ipoint, mate, bi, bj, myThid) \\ |
| 137 |
\\ |
| 138 |
where \> lev \>= Model Level at which the diagnostic is desired \\ |
| 139 |
\> undef \>= Fill value to be used when diagnostic is undefined \\ |
| 140 |
\> qtmp \>= Time-Averaged Diagnostic Output \\ |
| 141 |
\> ipoint \>= Pointer into qdiag array - from idiag array in common \\ |
| 142 |
\> mate \>= Diagnostic mate pointer number \\ |
| 143 |
\> bi \>= X-direction process(or) number \\ |
| 144 |
\> bj \>= Y-direction process(or) number \\ |
| 145 |
\> myThid \>= Current Thread number \\ |
| 146 |
\end{tabbing} |
| 147 |
|
| 148 |
\noindent |
| 149 |
{\bf diagnostics\_add2list}: This subroutine enables a diagnostic from the Diagnostic Menu, meaning |
| 150 |
that space is allocated for the diagnostic and the model routines will increment the |
| 151 |
diagnostic value during execution. This routine is the underlying interface routine |
| 152 |
for defining a new permanent diagnostic in the main model or in a package. The calling sequence is: |
| 153 |
|
| 154 |
\noindent |
| 155 |
\begin{tabbing} |
| 156 |
XXXXXXXXX\=XXXXXX\= \kill |
| 157 |
\> call diagnostics\_add2list( diagNum,diagName, diagCode, \\ |
| 158 |
\> diagUnits, diagTitle, myThid ) \\ |
| 159 |
\\ |
| 160 |
where \> diagNum \>=Diagnostic number - Output from routine \\ |
| 161 |
\> diagName \>=character*8 diagnostic name \\ |
| 162 |
\> diagCode \>=character*16 parsing code (see description of gdiag below) \\ |
| 163 |
\> diagUnits \>=Diagnostic units (character*16) \\ |
| 164 |
\> diagTitle \>=Diagnostic title or long name (up to character*80) \\ |
| 165 |
\> myThid \>=Current Thread number \\ |
| 166 |
\end{tabbing} |
| 167 |
|
| 168 |
\noindent |
| 169 |
{\bf clrdiag}: This subroutine initializes the values of model diagnostics to zero, and is |
| 170 |
particularly useful when called from user output routines to re-initialize diagnostics |
| 171 |
during the run. The calling sequence is: |
| 172 |
|
| 173 |
\noindent |
| 174 |
\begin{tabbing} |
| 175 |
XXXXXXXXX\=XXXXXX\= \kill |
| 176 |
\> call diagnostics\_clrdiag (jpoint, ipoint, myThid) \\ |
| 177 |
\\ |
| 178 |
where \> jpoint \>= Diagnostic number from menu - from jdiag array \\ |
| 179 |
ipoint \>= Pointer number into qdiag array - from idiag array \\ |
| 180 |
\> myThid \>=Current Thread number \\ |
| 181 |
\end{tabbing} |
| 182 |
|
| 183 |
\noindent |
| 184 |
The diagnostics are computed at various times and places within the GCM. Because the |
| 185 |
MIT GCM may employ a staggered grid, diagnostics may be computed at grid box centers, |
| 186 |
corners, or edges, and at the middle or edge in the vertical. Some diagnostics are scalars, |
| 187 |
while others are components of vectors. An internal array is defined which contains |
| 188 |
information concerning various grid attributes of each diagnostic. The GDIAG |
| 189 |
array (in common block \\diagnostics in file DIAGNOSTICS.h) is internally defined as a |
| 190 |
character*8 variable, and is equivalenced to a character*1 "parse" array in output in |
| 191 |
order to extract the grid-attribute information. The GDIAG array is described in |
| 192 |
Table \ref{tab:diagnostics:gdiag.tabl}. |
| 193 |
|
| 194 |
\begin{table} |
| 195 |
\caption{Diagnostic Parsing Array} |
| 196 |
\label{tab:diagnostics:gdiag.tabl} |
| 197 |
\begin{center} |
| 198 |
\begin{tabular}{ |c|c|l| } |
| 199 |
\hline |
| 200 |
\multicolumn{3}{|c|}{\bf Diagnostic Parsing Array} \\ |
| 201 |
\hline |
| 202 |
\hline |
| 203 |
Array & Value & Description \\ |
| 204 |
\hline |
| 205 |
parse(1) & $\rightarrow$ S & Scalar Diagnostic \\ |
| 206 |
& $\rightarrow$ U & U-vector component Diagnostic \\ |
| 207 |
& $\rightarrow$ V & V-vector component Diagnostic \\ \hline |
| 208 |
parse(2) & $\rightarrow$ U & C-Grid U-Point \\ |
| 209 |
& $\rightarrow$ V & C-Grid V-Point \\ |
| 210 |
& $\rightarrow$ M & C-Grid Mass Point \\ |
| 211 |
& $\rightarrow$ Z & C-Grid Vorticity (Corner) Point \\ \hline |
| 212 |
parse(3) & $\rightarrow$ R & Not Currently in Use \\ \hline |
| 213 |
parse(4) & $\rightarrow$ P & Positive Definite Diagnostic \\ \hline |
| 214 |
parse(5) & $\rightarrow$ C & Counter Diagnostic \\ |
| 215 |
& $\rightarrow$ D & Disabled Diagnostic for output \\ \hline |
| 216 |
parse(6-8) & $\rightarrow$ C & 3-digit integer corresponding to \\ |
| 217 |
& & vector or counter component mate \\ \hline |
| 218 |
\end{tabular} |
| 219 |
\addcontentsline{lot}{section}{Table 3: Diagnostic Parsing Array} |
| 220 |
\end{center} |
| 221 |
\end{table} |
| 222 |
|
| 223 |
|
| 224 |
\noindent |
| 225 |
As an example, consider a diagnostic whose associated GDIAG parameter is equal |
| 226 |
to ``UU 002''. From GDIAG we can determine that this diagnostic is a |
| 227 |
U-vector component located at the C-grid U-point. |
| 228 |
Its corresponding V-component diagnostic is located in Diagnostic \# 002. |
| 229 |
|
| 230 |
\noindent |
| 231 |
In this way, each Diagnostic in the model has its attributes (ie. vector or scalar, |
| 232 |
C-grid location, etc.) defined internally. The Output routines use this information |
| 233 |
in order to determine what type of transformations need to be performed. Any |
| 234 |
interpolations are done at the time of output rather than during each model step. |
| 235 |
In this way the User has flexibility in determining the type of gridded data which |
| 236 |
is output. |
| 237 |
|
| 238 |
\subsubsection{Usage Notes} |
| 239 |
\label{sec:diagnostics:usersguide} |
| 240 |
|
| 241 |
\noindent |
| 242 |
To use the diagnostics package, other than enabling it in packages.conf |
| 243 |
and turning the usediagnostics flag in data.pkg to .TRUE., there are two |
| 244 |
further steps the user must take to enable the diagnostics package for |
| 245 |
output of quantities that are already defined in the GCM under an experiment's |
| 246 |
configuration of packages. A namelist must be supplied in the run directory |
| 247 |
called data.diagnostics, and the file DIAGNOSTICS\_SIZE.h must be included in the |
| 248 |
code directory. The steps for defining a new (permanent or experiment-specific |
| 249 |
temporary) diagnostic quantity will be outlined later. |
| 250 |
|
| 251 |
\noindent The namelist will activate a user-defined list of diagnostics quantities |
| 252 |
to be computed, specify the frequency and type of output, the number of levels, and |
| 253 |
the name of all the separate output files. A sample data.diagnostics namelist file: |
| 254 |
|
| 255 |
\noindent |
| 256 |
$\#$ Diagnostic Package Choices \\ |
| 257 |
$\&$diagnostics\_list \\ |
| 258 |
frequency(1) = 86400., \ \\ |
| 259 |
levels(1,1) = 1., \ \\ |
| 260 |
fields(1,1) = 'RSURF ', \ \\ |
| 261 |
filename(1) = 'surface', \ \\ |
| 262 |
frequency(2) = 86400., \ \\ |
| 263 |
levels(1,2) = 1.,2.,3.,4.,5., \ \\ |
| 264 |
fields(1,2) = 'UVEL ','VVEL ', \ \\ |
| 265 |
filename(2) = 'diagout1', \ \\ |
| 266 |
frequency(3) = 3600., \ \\ |
| 267 |
fields(1,3) = 'UVEL ','VVEL ','PRESSURE', \ \\ |
| 268 |
filename(3) = 'diagout2', \ \\ |
| 269 |
fileflags(3) = ' P1 ', \ \\ |
| 270 |
$\&$end \ \\ |
| 271 |
|
| 272 |
\noindent |
| 273 |
In this example, there are two output files that will be generated |
| 274 |
for each tile and for each output time. The first set of output files |
| 275 |
has the prefix diagout1, does time averaging every 86400. seconds, |
| 276 |
(frequency is 86400.), and will write fields which are multiple-level |
| 277 |
fields at output levels 1-5. The names of diagnostics quantities are |
| 278 |
UVEL and VVEL. The second set of output files |
| 279 |
has the prefix diagout2, does time averaging every 3600. seconds, |
| 280 |
includes fields which are multiple-level fields, levels output are 1-5, |
| 281 |
and the names of diagnostics quantities are THETA and SALT. |
| 282 |
|
| 283 |
\noindent |
| 284 |
The user must assure that enough computer memory is allocated for the diagnostics |
| 285 |
and the output streams selected for a particular experiment. This is acomplished by |
| 286 |
modifying the file DIAGNOSTICS\_SIZE.h and including it in the experiment code directory. |
| 287 |
The parameters that should be checked are called numdiags, numlists, numperlist, and |
| 288 |
diagSt\_size. |
| 289 |
|
| 290 |
\noindent numdiags (and diagSt\_size): \\ |
| 291 |
\noindent All GCM diagnostic quantities are stored in the single diagnostic array QDIAG |
| 292 |
which is located in the file \\ \filelink{pkg/diagnostics/DIAGNOSTICS.h}{pkg-diagnostics-DIAGNOSTICS.h}.\\ |
| 293 |
and has the form:\\ |
| 294 |
common /diagnostics/ qdiag(1-Olx,sNx+Olx,1-Olx,sNx+Olx,numdiags,Nsx,Nsy) \\ |
| 295 |
\noindent |
| 296 |
The first two-dimensions of qdiag correspond to the horizontal dimension of a given diagnostic, |
| 297 |
and the third dimension of qdiag is used to identify diagnostic fields and levels combined. In |
| 298 |
order to minimize the memory requirement of the model for diagnostics, the default GCM |
| 299 |
executable is compiled with room for only one horizontal diagnostic array, or with |
| 300 |
numdiags set to Nr. In order for the User to enable more than 1 three-dimensional diagnostic, |
| 301 |
the size of the diagnostics common must be expanded to accomodate the desired diagnostics. |
| 302 |
This can be accomplished by manually changing the parameter numdiags in the |
| 303 |
file \filelink{pkg/diagnostics/DIAGNOSTICS\_SIZE.h}{pkg-diagnostics-DIAGNOSTICS\_SIZE.h}. |
| 304 |
numdiags should be set greater than or equal to the sum of all the diagnostics activated |
| 305 |
for output each multiplied by the number of levels defined for that diagnostic quantity. |
| 306 |
For the above example, there are 4 multiple level fields, which the diagnostics menu |
| 307 |
(see below) indicates are defined at the GCM vertical resolution, Nr. The value of |
| 308 |
numdiag in DIAGNOSTICS\_SIZE.h would therefore be equal to 4*Nr, or, say 40 if $Nr=10$. |
| 309 |
|
| 310 |
\noindent numlists and numperlist: \\ |
| 311 |
\noindent The parameter numlists must be set greater than or equal to the number of |
| 312 |
separate output streams that the user specifies in the namelist file data.diagnostics. |
| 313 |
The parameter numperlist corresponds to the number of diagnostics requested in each |
| 314 |
output stream. |
| 315 |
|
| 316 |
\noindent |
| 317 |
In order to define and include as part of the diagnostic output any field |
| 318 |
that is desired for a particular experiment, two steps must be taken. The |
| 319 |
first is to enable the ``User Diagnostic'' in data.diagnostics. This is |
| 320 |
accomplished by adding one of the ``User Diagnostic'' field names (UDIAG1 through |
| 321 |
UDIAG10, for multi-level fields, or SDIAG1 through SDIAG10 for single level |
| 322 |
fields) to the data.diagnostics namelist in one of the output streams. These |
| 323 |
fields are listed in the diagnostics menu. The second step is to |
| 324 |
add a call to diagnostics\_fill from the subroutine in which the quantity |
| 325 |
desired for diagnostic output is computed. |
| 326 |
|
| 327 |
\noindent |
| 328 |
In order to add a new diagnostic to the permanent set of diagnostics that the |
| 329 |
main model or any package contains as part of its diagnostics menu, the subroutine |
| 330 |
diagnostics\_add2list should be called during the initialization phase of the |
| 331 |
main model or package. For the main model, the call should be made from |
| 332 |
subroutine diagnostics\_main\_init, and for a package, the call should probably |
| 333 |
be made from somewhere in the packages\_init\_fixed sequence (probaby from inside |
| 334 |
the particular package's init\_fixed routine). A typical code sequence to set the |
| 335 |
input arguments to diagnostics\_add2list would look like: |
| 336 |
|
| 337 |
\noindent |
| 338 |
\begin{tabbing} |
| 339 |
XXXXXXXXX\=XXXXXX\= \kill |
| 340 |
\> diagName = 'THETA ' \\ |
| 341 |
\> diagTitle = 'Potential Temperature (degC,K)' \\ |
| 342 |
\> diagUnits = 'Degrees K ' \\ |
| 343 |
\> diagCode = 'SM MR ' \\ |
| 344 |
\> CALL DIAGNOSTICS\_ADD2LIST( diagNum, \\ |
| 345 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
| 346 |
\\ |
| 347 |
\end{tabbing} |
| 348 |
|
| 349 |
\noindent If the new diagnostic quantity is associated with either a vector |
| 350 |
pair or a diagnostic counter, the diagCode argument must be filled with the |
| 351 |
proper index for the ``mate''. The output argument from diagnostics\_add2list |
| 352 |
that is called diagNum here contains a running total of the number of diagnostics |
| 353 |
defined in the code up to any point during the run. The sequence number for the |
| 354 |
next two diagnostics defined (the two components of the vector pair, for instance) |
| 355 |
will be diagNum+1 and diagNum+2. The definition of the first component of the vector |
| 356 |
pair must fill the ``mate'' segment of the diagCode as diagnostic number diagNum+2. |
| 357 |
Since the subroutine increments diagNum, the definition of the second component of |
| 358 |
the vector fills the ``mate'' part of diagCode with diagNum. A code sequence for |
| 359 |
this case would look like: |
| 360 |
|
| 361 |
\noindent |
| 362 |
\begin{tabbing} |
| 363 |
XXXXXXXXX\=XXXXXX\= \kill |
| 364 |
\> diagName = 'UVEL ' \\ |
| 365 |
\> diagTitle = 'Zonal Velocity ' \\ |
| 366 |
\> diagUnits = 'm / sec ' \\ |
| 367 |
\> diagCode = 'SM MR ' \\ |
| 368 |
\> write(diagCode,'(A,I3.3,A)') 'VV ', diagNum+2 ,'MR ' \\ |
| 369 |
\> call diagnostics\_add2list( diagNum, \\ |
| 370 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
| 371 |
\> diagName = 'VVEL ' \\ |
| 372 |
\> diagTitle = 'Meridional Velocity ' \\ |
| 373 |
\> diagUnits = 'm / sec ' \\ |
| 374 |
\> diagCode = 'SM MR ' \\ |
| 375 |
\> write(diagCode,'(A,I3.3,A)') 'VV ', diagNum ,'MR ' \\ |
| 376 |
\> call diagnostics\_add2list( diagNum, \\ |
| 377 |
\> I diagName, diagCode, diagUnits, diagTitle, myThid ) \\ |
| 378 |
\\ |
| 379 |
\end{tabbing} |
| 380 |
|
| 381 |
\input{part7/diagnostics-menu.tex} |
| 382 |
|
| 383 |
\newpage |
| 384 |
\noindent For a list of the diagnostic fields available in the |
| 385 |
different MITgcm packages, follow the link to the diagnostics menu |
| 386 |
in the manual section describing the package: |
| 387 |
|
| 388 |
\filelink{part6/fizhi-diagnostics-menu.tex}{pkg-fizhi-fizhi-diagnostics-menu.tex} |
| 389 |
|
| 390 |
\subsubsection{Dos and Donts} |
| 391 |
|
| 392 |
\subsubsection{Diagnostics Reference} |
| 393 |
|
Parent Directory
| 
Revision Log
| 
Revision Graph