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