1 | \newpage |
---|
2 | \chapter{Interfacing a component code with OASIS3-MCT} |
---|
3 | \label{sec_modelinterfacing} |
---|
4 | |
---|
5 | At run-time, OASIS3-MCT performs parallel exchange of coupling data between parallel |
---|
6 | components and sub-components and allows remapping (interpolation), time integration or accumulation and other transformations of these coupling fields. |
---|
7 | |
---|
8 | This chapter describes how to adapt the component codes to couple them through OASIS3-MCT. |
---|
9 | |
---|
10 | OASIS3-MCT supports coupling exchanges between parallel |
---|
11 | components and sub-components deployed in diverse |
---|
12 | configurations; the different possibilities and how to use |
---|
13 | the OASIS3-MCT library accordingly are described in section |
---|
14 | \ref{sec_deploy}. |
---|
15 | |
---|
16 | The OASIS3-MCT Application Programming Interface (API) includes different classes of modules or routines that are described in details in sections \ref{API}, \ref{APIC} and \ref{APIpython} for Fortran, C and python codes respectively. |
---|
17 | In section \ref{sec_notes}, the reader will also find an overview of the MCT library (see \ref{subsec_MCT}) and additional notes on how to exchange scalars (see \ref{subsec_scalar}), how to to reproduce different coupling |
---|
18 | algorithms with OASIS3-MCT using the {\tt LAG} index (see \ref{subsec_lag}), and on the {\tt |
---|
19 | SEQ} index (see \ref{subsec_sec}). |
---|
20 | |
---|
21 | \section{Configurations of components supported} |
---|
22 | \label{sec_deploy} |
---|
23 | |
---|
24 | Since OASIS3-MCT\_3.0 release, coupling exchanges between components and |
---|
25 | sub-components deployed in a much larger diversity of configurations |
---|
26 | are supported. This is illustrated on figure |
---|
27 | \ref{Fig_coupling_layouts_a} and how to use the OASIS3-MCT library |
---|
28 | accordingly is detailed on figure \ref{Fig_coupling_layouts_b}. All |
---|
29 | OASIS3-MCT API routines are also described in details in sections |
---|
30 | \ref{API}, \ref{APIC} and \ref{APIpython}. |
---|
31 | |
---|
32 | We call here an ``executable'' a compiled code |
---|
33 | forming a part of or the whole coupled system (started with the |
---|
34 | mpirun or mpiexec command). A ``component'' is the ensemble of |
---|
35 | processes, or tasks, within the coupled system calling {\tt oasis\_init\_comp} |
---|
36 | with the same {\tt comp\_name} argument (see section |
---|
37 | \ref{init_comp}). A ``sub-component'' is the subset of tasks within a |
---|
38 | component sending or receiving coupling fields on a specific grid; |
---|
39 | of course, a component may have only one sub-component |
---|
40 | that gathers all its tasks. |
---|
41 | |
---|
42 | Practical examples of how to use the OASIS3-MCT library are also given in {\tt examples/} {\tt tutorial} and {\tt examples/test\_1bin\_ocnice} (see sections \ref{subsec_tutorial} and \ref{subsec_1bin_ocnice}).XXXXXXXXXXXXXX |
---|
43 | |
---|
44 | Since OASIS3-MCT\_3.0, it is possible to (the text between [ and ] refers to figure \ref{Fig_coupling_layouts_a}) : |
---|
45 | |
---|
46 | \begin{figure} |
---|
47 | \includegraphics[scale=.6]{figures/coupling_layouts_a} |
---|
48 | \caption{The different configuration of components supported by OASIS3-MCT\_3.0. Two executables {\tt exe1} and {\tt exe2} are running concurrently on separate sets of MPI tasks (0-5 for {\tt exe1} and 6-37 for {\tt exe2}). Executable {\tt exe1} includes only one component {\tt comp1} that has coupling fields defined on only one grid {\tt grid1} (decomposed on all its 6 tasks). Executable {\tt exe2} includes 3 components, {\tt comp2}, {\tt comp3}, and {\tt comp4} running concurrently respectively on tasks 6-11, 12-33 and 34-37. Component {\tt comp2} participates in the coupling with fields defined on only one coupling grid {\tt grid2} (decomposed on all its 5 tasks) while {\tt comp4} does not participate at all in the coupling. |
---|
49 | Component {\tt comp3} has 3 sub-components, respectively exchanging |
---|
50 | coupling fields defined on {\tt grid3} (tasks 12-21), {\tt grid4} |
---|
51 | (tasks 22-30) and {\tt grid5} (tasks 12-26, therefore overlaping with both {\tt |
---|
52 | grid3} and {\tt grid4}); finally, {\tt comp3} has 3 tasks (31-33) |
---|
53 | not involved in the coupling. Sub-components exe2-comp3-grid3 and |
---|
54 | exe2-comp3-grid5, or sub-components exe2-comp3-grid4 and |
---|
55 | exe2-comp3-grid5 are examples of coupling between sub-components running sequentially on overlapping sets of tasks.} |
---|
56 | \label{Fig_coupling_layouts_a} |
---|
57 | \end{figure} |
---|
58 | |
---|
59 | \begin{figure} |
---|
60 | \includegraphics[scale=.6]{figures/coupling_layouts_b} |
---|
61 | \caption{The sequence of OASIS3-MCT calls that have to be implemented in the codes so to allow the configuration of components described on figure \ref{Fig_coupling_layouts_a}. |
---|
62 | Each MPI tasks has to call {\tt oasis\_init\_comp} once with the name |
---|
63 | of its component as $2^{nd}$ argument. As none of {\tt comp4} tasks is |
---|
64 | participating to the coupling, {\tt comp4} tasks calls {\tt |
---|
65 | oasis\_init\_comp} with {\tt coupled=.false.â} as $4^{th}$ argument |
---|
66 | and does not call any other OASIS3-MCT routine. As some of {\tt comp3} |
---|
67 | tasks are participating to the coupling, all {\tt comp3} tasks have to |
---|
68 | call {\tt oasis\_init\_comp}, {\tt oasis\_get\_localcomm}, {\tt |
---|
69 | oasis\_create\_couplcomm}, {\tt oasis\_enddef} and {\tt |
---|
70 | oasis\_terminate} (these are the only routine to be called by {\tt |
---|
71 | comp3} tasks 31-33 not participating to the coupling). To initialise |
---|
72 | the coupling exchanges, the tasks of a sub-component holding a field |
---|
73 | decomposed on a specific grid have to call the {\tt |
---|
74 | oasis\_def\_partition} to express the decomposition of the grid, |
---|
75 | {\tt oasis\_def\_var} to declare the coupling field and {\tt |
---|
76 | oasis\_enddef}. Finally, the tasks of a sub-component exchanging |
---|
77 | coupling fields have to call {\tt oasis\_put} and {\tt oasis\_get} accordingly. |
---|
78 | } |
---|
79 | \label{Fig_coupling_layouts_b} |
---|
80 | \end{figure} |
---|
81 | |
---|
82 | \begin{itemize} |
---|
83 | |
---|
84 | \item to implement coupling exchanges between two components or |
---|
85 | sub-components running concurrently on separate sets of tasks within two different executables (as before) [A, D, E, J]; |
---|
86 | \item to implement coupling exchanges between two components or |
---|
87 | sub-components running concurrently on separate sets of tasks within one same executable [B, F, I]; |
---|
88 | \item to implement coupling exchanges within one executable between |
---|
89 | two concurrent sub-components [C] |
---|
90 | \item to implement coupling exchanges within one executable between |
---|
91 | two sub-components running sequentially on overlapping sets of tasks (i.e. a task can be coupled to itself calling both the ``putâ and the ``getâ of the exchange) [G, H] |
---|
92 | \item to have some tasks of a component not participating to the coupling exchanges [tasks 31-33 of {\tt exe2-comp3}] |
---|
93 | \item to have all processes of a component not participating to the coupling exchanges [{\tt exe2-comp4}, tasks 34-37] |
---|
94 | |
---|
95 | \end{itemize} |
---|
96 | |
---|
97 | The sequence of OASS3-MCT API routines that have to be called in the different cases is detailed on figure \ref{Fig_coupling_layouts_b}. These routines are also described in detail in the next section. |
---|
98 | |
---|
99 | \section{OASIS3-MCT Fortran API} |
---|
100 | \label{API} |
---|
101 | |
---|
102 | To interact with the rest of the coupled system, few calls of the |
---|
103 | OASIS3-MCT library routines, which sources can be found in {\tt |
---|
104 | oasis3-mct/lib/psmile} directory, have to be implemented in |
---|
105 | component Fortran codes. They belong to the following classes: |
---|
106 | \begin{enumerate} |
---|
107 | \item Module to use (section \ref{subsubsec_Use}) |
---|
108 | \item Initialisation (section \ref{subsubsec_Initialisation}) |
---|
109 | \item Partition definition (section \ref{subsubsec_Partition}) |
---|
110 | \item Grid data file definition (section \ref{subsubsec_griddef}) |
---|
111 | \item Coupling-I/O field declaration (section |
---|
112 | \ref{subsubsec_Declaration}) |
---|
113 | \item End of definition phase (section |
---|
114 | \ref{subsubsec_Endofdefinition}) |
---|
115 | \item Coupling-I/O field sending and receiving (section |
---|
116 | \ref{subsubsec_sendingreceiving}) |
---|
117 | \item Termination (section \ref{subsubsec_Termination}) |
---|
118 | \item Optional auxiliary routines (section |
---|
119 | \ref{subsubsec_auxroutines}) |
---|
120 | \end{enumerate} |
---|
121 | |
---|
122 | \subsection{Module to use in the code} |
---|
123 | \label{subsubsec_Use} |
---|
124 | % {Use} |
---|
125 | |
---|
126 | To use OASIS3-MCT library, a user needs to add in his code: |
---|
127 | |
---|
128 | \begin{itemize} |
---|
129 | |
---|
130 | \item {\tt USE mod\_oasis} |
---|
131 | |
---|
132 | or |
---|
133 | |
---|
134 | \item {\tt USE mod\_prism} |
---|
135 | |
---|
136 | \end{itemize} |
---|
137 | |
---|
138 | Both use statements are valid but only one needs to be used in a particular component. This single use statement provides all methods required. The methods, datatypes, and capabilities |
---|
139 | are identical for both the {\tt mod\_prism} or {\tt mod\_oasis} |
---|
140 | interfaces, the only difference being the name of the interface. The |
---|
141 | interface in module {\tt mod\_prism} is provided for backwards |
---|
142 | compatability with prior versions of OASIS3. Use of module {\tt |
---|
143 | mod\_oasis} is recommended and provides access to a set of updated |
---|
144 | routine names that will continue to evolve in the future, always |
---|
145 | ensuring backward compatibility. In the following sections, both the |
---|
146 | {\tt mod\_prism} and {\tt mod\_oasis} interface names are defined and |
---|
147 | a single description of the interface arguments is provided. |
---|
148 | |
---|
149 | \subsection{Initialisation} |
---|
150 | \label{subsubsec_Initialisation} |
---|
151 | % {Initialisation} |
---|
152 | |
---|
153 | \subsubsection{Coupling initialisation} |
---|
154 | \label{init_comp} |
---|
155 | |
---|
156 | \begin{itemize} |
---|
157 | |
---|
158 | \item {\tt CALL oasis\_init\_comp (compid, comp\_name, kinfo, coupled, commworld)} |
---|
159 | \item {\tt CALL prism\_init\_comp\_proto (compid, comp\_name, kinfo, coupled, commworld)} |
---|
160 | |
---|
161 | \begin{itemize} |
---|
162 | \item {\tt compid [INTEGER; OUT]}: returned component ID |
---|
163 | \item {\tt comp\_name [CHARACTER; IN]}: component name; maximum length of 80 characters |
---|
164 | \item {\tt kinfo [INTEGER; OUT]}: returned error code |
---|
165 | \item {\tt coupled [LOGICAL, OPTIONAL; IN]}: flag to specify if the calling task is participating or not to the coupling ({\tt .true.} by default). |
---|
166 | \item {\tt commworld [INTEGER, OPTIONAL; IN]} : optional argument to specify the global communicator gathering the components of the coupled model. |
---|
167 | If not specified, {\tt MPI\_COMM\_WORLD} will be used as the default communicator to startup. All components of the coupled model must |
---|
168 | specify the same {\tt commworld} argument. |
---|
169 | |
---|
170 | \end{itemize} |
---|
171 | |
---|
172 | This routine must called by all tasks of all components whether of not they are involved in the coupling \footnote{The component may also call MPI\_Init explicitly, but if so, has to call it before calling {\tt oasis\_init\_comp}; in this case, the component also has to call MPI\_Finalize explicitly, but only after calling {\tt oasis\_terminate}.}. |
---|
173 | |
---|
174 | A component is defined as the ensemble of tasks calling {\tt |
---|
175 | oasis\_init\_comp} with the same {\tt comp} {\tt \_name} |
---|
176 | argument. If and only if all tasks of a component are excluded from |
---|
177 | the coupling, the logical {\tt coupled} can be set to {\tt .false.} |
---|
178 | for this component tasks; in this case, {\tt oasis\_init\_comp} is the |
---|
179 | only API routine that needs to be called by the component tasks. If at |
---|
180 | least one tasks of a component is participating to the coupling, all |
---|
181 | component tasks have to call {\tt oasis\_init\_comp} with {\tt |
---|
182 | coupled=.true.} (by default); in this case, the component tasks not |
---|
183 | participating to the coupling will also have to call |
---|
184 | {\tt oasis\_get\_localcomm}, {\tt oasis\_create\_couplcomm}, {\tt oasis\_enddef} and {\tt oasis\_terminate}. |
---|
185 | \end{itemize} |
---|
186 | |
---|
187 | \subsubsection{Communicator for internal parallelisation} |
---|
188 | \label{subsec_MPI1} |
---|
189 | |
---|
190 | \begin{itemize} |
---|
191 | \item {\tt CALL oasis\_get\_localcomm (local\_comm, kinfo )} |
---|
192 | \item {\tt CALL prism\_get\_localcomm\_proto (local\_comm, kinfo )} |
---|
193 | |
---|
194 | \begin{itemize} |
---|
195 | \item {\tt local\_comm [INTEGER; OUT]}: value of local communicator |
---|
196 | \item {\tt kinfo [INTEGER; OUT]}: returned error code. |
---|
197 | \end{itemize} |
---|
198 | |
---|
199 | This routine returns the value of a local communicator gathering |
---|
200 | only the tasks of the component, i.e. the tasks that called {\tt |
---|
201 | oasis\_init\_comp} with the same {\tt comp\_name} |
---|
202 | argument. |
---|
203 | |
---|
204 | This may be needed as all executables of the coupled system are started in a pseudo-MPMD |
---|
205 | mode with MPI1 and therefore share automatically the same MPI\_COMM\_WORLD |
---|
206 | communicator. Another communicator has to be used for the internal |
---|
207 | parallelisation of each component. OASIS3-MCT creates this local |
---|
208 | communicator {\tt local\_comm} based on the value of the {\tt |
---|
209 | comp\_name} argument in the {\tt oasis\_init\_comp} call. |
---|
210 | |
---|
211 | Retrieving a local communicator {\tt local\_comm} is also needed if |
---|
212 | {\tt oasis\_create\_couplcomm} is called, as {\tt local\_comm} is an argument of this routine (see below). |
---|
213 | |
---|
214 | % With CLIM-MPI2, OASIS3 executable spawns the component |
---|
215 | % executables at the beginning of the run; the components keep their |
---|
216 | % internal parallelisation context unchanged with respect to their |
---|
217 | % standalone mode. In this case, calling the |
---|
218 | % prism\_get\_localcomm\_proto routine is useless but if called, the |
---|
219 | % communicator MPI\_COMM\_WORLD will be returned as local |
---|
220 | % communicator. |
---|
221 | \end{itemize} |
---|
222 | |
---|
223 | \begin{itemize} |
---|
224 | \item {\tt CALL oasis\_create\_couplcomm(icpl, local\_comm, |
---|
225 | coupl\_comm, kinfo)} |
---|
226 | \item {\tt CALL prism\_create\_couplcomm(icpl, local\_comm, |
---|
227 | coupl\_comm, kinfo)} |
---|
228 | \begin{itemize} |
---|
229 | \item {\tt icpl [INTEGER; IN]}: coupling process flag |
---|
230 | \item {\tt local\_comm [INTEGER; IN]}: MPI communicator with all |
---|
231 | processes of the component |
---|
232 | \item {\tt coupl\_comm [INTEGER; OUT]}: returned MPI communicator |
---|
233 | gathering only component processes participating in the coupling |
---|
234 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
235 | \end{itemize} |
---|
236 | |
---|
237 | This routine creates a coupling communicator for a subset of |
---|
238 | processes. It is mandatory to call this routine if only a subset of |
---|
239 | the component processes participate in the coupling (e.g. {\tt comp3} in figure |
---|
240 | \ref{Fig_coupling_layouts_b}); in that case, the processes |
---|
241 | involved in the coupling have to call it with icpl=1 while the |
---|
242 | other have to call it with icpl = MPI UNDEFINED. Argument |
---|
243 | local\_comm is the MPI communicator associated with all processes |
---|
244 | of the component returned by oasis\_get\_localcomm. The new coupling |
---|
245 | communicator is returned in coupl\_comm. |
---|
246 | |
---|
247 | \end{itemize} |
---|
248 | If this communicator already exists in the code, the component should |
---|
249 | simply provide it to OASIS3-MCT with: |
---|
250 | |
---|
251 | \begin{itemize} |
---|
252 | \item {\tt CALL oasis\_set\_couplcomm(coupl\_comm, kinfo)} |
---|
253 | \item {\tt CALL prism\_set\_couplcomm(coupl\_comm, kinfo)} |
---|
254 | \begin{itemize} |
---|
255 | \item {\tt coupl\_comm [INTEGER; IN]}: MPI communicator gathering |
---|
256 | only component processes participating in the coupling |
---|
257 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
258 | \end{itemize} |
---|
259 | |
---|
260 | This routine allows to provide a local coupling communicator to |
---|
261 | OASIS3-MCT, given that it already exists in the code. The value of |
---|
262 | {\tt coupl\_comm} must be the value of this local coupling |
---|
263 | communicator for the processes participating to the coupling and it |
---|
264 | must be {\tt MPI\_COMM\_NULL} for processes not involved in the |
---|
265 | coupling. |
---|
266 | \end{itemize} |
---|
267 | |
---|
268 | \subsection{Partition definition} |
---|
269 | \label{subsubsec_Partition} |
---|
270 | |
---|
271 | The coupling fields sent or received by a component are usually |
---|
272 | scattered among the different component processes. With OASIS3-MCT, |
---|
273 | all processes exchanging coupling data have to express in a global index space the local |
---|
274 | partitioning of the different grids onto which the data is expressed (see \ref{subsubsec_griddef} for the grid definition). |
---|
275 | The processes not implied in the |
---|
276 | coupling do not have to call this routine (for backward compatibility with OASIS3-MCT\_2.0, |
---|
277 | they may still call it describing a null partition, i.e. with {\tt ig\_paral(:)=0}). |
---|
278 | |
---|
279 | \begin{itemize} |
---|
280 | |
---|
281 | \vspace{0.2cm} |
---|
282 | \item {\tt CALL oasis\_def\_partition (il\_part\_id, ig\_paral, |
---|
283 | kinfo, ig\_size, name)} or |
---|
284 | \item {\tt CALL prism\_def\_partition\_proto (il\_part\_id, ig\_paral, |
---|
285 | kinfo, ig\_size, name)} |
---|
286 | |
---|
287 | \begin{itemize} |
---|
288 | \item {\tt il\_part\_id [INTEGER; OUT]}: partition ID |
---|
289 | \item {\tt ig\_paral [INTEGER, DIMENSION(:), IN]}: vector of |
---|
290 | integers describing the local grid partition in the global index space; |
---|
291 | has a different expression depending on the type of the partition; |
---|
292 | in OASIS3-MCT, 5 types of partition are supported: Serial (no |
---|
293 | partition), Apple, Box, Orange, and Points (see below). |
---|
294 | \item {\tt kinfo [INTEGER; OUT]}: returned error code. |
---|
295 | \item {\tt ig\_size [INTEGER, OPTIONAL, IN]}: Optional argument, mandatory |
---|
296 | if the coupling data is exchanged for only a subdomain of the |
---|
297 | global grid; in this case, {\tt ig\_size} must give the total number of grid points. |
---|
298 | \item {\tt name [CHARACTER, OPTIONAL, IN]}: Optional argument associating a name to the partition, |
---|
299 | mandatory if oasis\_def\_partition is called either for a grid |
---|
300 | decomposed not across all the processes of a component or if the related |
---|
301 | oasis\_def\_partition are not |
---|
302 | called in the same order on the different component processes; |
---|
303 | this argument is new since OASIS3-MCT\_3.0 and is linked to the |
---|
304 | greater flexibility in the configuration of components supported |
---|
305 | (see \ref{sec_deploy}); it has a maximum length of 120 characters. |
---|
306 | \end{itemize} |
---|
307 | \end{itemize} |
---|
308 | |
---|
309 | \subsubsection{Serial (no partition)} |
---|
310 | |
---|
311 | This is the choice for a grid entirely supported by only one process . In this case, we have {\tt |
---|
312 | ig\_paral(1:3)}: |
---|
313 | \begin{itemize} |
---|
314 | \item {\tt ig\_paral(1)} = 0 (indicates a Serial ``partition'') |
---|
315 | \item {\tt ig\_paral(2)} = 0 |
---|
316 | \item {\tt ig\_paral(3)} = the total grid size. |
---|
317 | \end{itemize} |
---|
318 | |
---|
319 | \subsubsection{Apple partition} |
---|
320 | |
---|
321 | Each partition is a segment of the global domain, described by its |
---|
322 | global offset and its local size. In this case, we have {\tt |
---|
323 | ig\_paral(1:3)}: |
---|
324 | \begin{itemize} |
---|
325 | \item {\tt ig\_paral(1)} = 1 (indicates an Apple partition) |
---|
326 | \item {\tt ig\_paral(2)} = the segment global offset |
---|
327 | \item {\tt ig\_paral(3)} = the segment local size |
---|
328 | \end{itemize} |
---|
329 | |
---|
330 | Figure \ref{apple_partition} illustrates an Apple partition over 3 |
---|
331 | processes. |
---|
332 | \begin{figure} |
---|
333 | \includegraphics[scale=.6]{figures/apple_new} |
---|
334 | \caption{Apple partition. It is assumed here that the global index starts at |
---|
335 | 0 in the upper left corner.} |
---|
336 | \label{apple_partition} |
---|
337 | \end{figure} |
---|
338 | |
---|
339 | |
---|
340 | \subsubsection{Box partition} |
---|
341 | |
---|
342 | Each partition is a rectangular region of the global domain, described |
---|
343 | by the global offset of its upper left corner, and its local extents |
---|
344 | in the X and Y dimensions. The global extent in the X dimension must |
---|
345 | also be given. In this case, we have {\tt ig\_paral(1:5)}: |
---|
346 | \begin{itemize} |
---|
347 | \item {\tt ig\_paral(1)} = 2 (indicates a Box partition) |
---|
348 | \item {\tt ig\_paral(2)} = the upper left corner global offset |
---|
349 | \item {\tt ig\_paral(3)} = the local extent in x |
---|
350 | \item {\tt ig\_paral(4)} = the local extent in y |
---|
351 | \item {\tt ig\_paral(5)} = the global extent in x. |
---|
352 | \end{itemize} |
---|
353 | |
---|
354 | Figure \ref{box_partition} illustrates a Box partition over 3 |
---|
355 | processes. |
---|
356 | |
---|
357 | \begin{figure} |
---|
358 | \includegraphics[scale=.6]{figures/box_new} |
---|
359 | \caption{Box partition. It is assumed here that the global index starts at 0 |
---|
360 | in the upper left corner.} |
---|
361 | \label{box_partition} |
---|
362 | \end{figure} |
---|
363 | |
---|
364 | \subsubsection{Orange partition} |
---|
365 | |
---|
366 | Each partition is an ensemble of segments in the global domain. Each |
---|
367 | segment is described by its global offset and its local extent. In |
---|
368 | this case, we have {\tt ig\_paral(1:N)} where {\tt N = 2 + 2*number of |
---|
369 | segments} |
---|
370 | % \footnote{As for the Box partition, the maximum number of segments |
---|
371 | % is presently 338; it can be increased by modifying the value of |
---|
372 | % {\tt Clim\_MaxSegments}}. |
---|
373 | |
---|
374 | \begin{itemize} |
---|
375 | \item {\tt ig\_paral(1)} = 3 (indicates a Orange partition) |
---|
376 | \item {\tt ig\_paral(2)} = the total number of segments for the |
---|
377 | partition (limited to 200 presently, see note for ig\_paral(4) for |
---|
378 | Box partition above) |
---|
379 | \item {\tt ig\_paral(3)} = the first segment global offset |
---|
380 | \item {\tt ig\_paral(4)} = the first segment local extent |
---|
381 | \item {\tt ig\_paral(5)} = the second segment global offset |
---|
382 | \item {\tt ig\_paral(6)} = the second segment local extent |
---|
383 | \item ... |
---|
384 | \item {\tt ig\_paral(N-1)} = the last segment global offset |
---|
385 | \item {\tt ig\_paral(N)} = the last segment local extent |
---|
386 | \end{itemize} |
---|
387 | |
---|
388 | Figure \ref{orange_partition} illustrates an Orange partition with 3 |
---|
389 | segments for one process. The other process partitions are not |
---|
390 | illustrated. |
---|
391 | |
---|
392 | \begin{figure} |
---|
393 | \includegraphics[scale=.6]{figures/orange_new} |
---|
394 | \caption{Orange partition for one process. It is assumed here that |
---|
395 | the global index starts at 0 in the upper left corner.} |
---|
396 | \label{orange_partition} |
---|
397 | \end{figure} |
---|
398 | |
---|
399 | \subsubsection{Points partition} |
---|
400 | \label{subsubsec_pointspart} |
---|
401 | |
---|
402 | This partition is a list of global indices associated with each |
---|
403 | process. The index naming |
---|
404 | is arbitrary but must be consistent between all processes involved |
---|
405 | in the partition description. In |
---|
406 | this case, we have {\tt ig\_paral(1:N)} where {\tt N = 2 + number of |
---|
407 | points} |
---|
408 | % \footnote{As for the Box partition, the maximum number of segments |
---|
409 | % is presently 338; it can be increased by modifying the value of |
---|
410 | % {\tt Clim\_MaxSegments}}. |
---|
411 | |
---|
412 | \begin{itemize} |
---|
413 | \item {\tt ig\_paral(1)} = 4 (indicates a Points partition) |
---|
414 | \item {\tt ig\_paral(2)} = number of points in the partition |
---|
415 | \item {\tt ig\_paral(3)} = the first global index |
---|
416 | \item {\tt ig\_paral(4)} = the second global index |
---|
417 | \item ... |
---|
418 | \item {\tt ig\_paral(N)} = the last global index |
---|
419 | \end{itemize} |
---|
420 | |
---|
421 | % {Partition definition} |
---|
422 | \subsection{Grid data file definition} |
---|
423 | \label{subsubsec_griddef} |
---|
424 | |
---|
425 | Grid data files (see section \ref{subsec_griddata}) are required by OASIS3-MCT for specific operations , i.e. {\em grids.nc} and {\em masks.nc} for |
---|
426 | {\tt SCRIPR} (see section \ref{subsec_interp}), and {\em masks.nc} and |
---|
427 | {\em areas.nc} for {\tt CONSERV} (see section |
---|
428 | \ref{subsec_cooking}). These grid data files can be created by the |
---|
429 | user before the run or can be written directly at run time by the components with the following routines. |
---|
430 | If a grid data files does not exist, the corresponding routine will create it; if the grid data file exists, the routine can be used to {\bf add} grid definition fields but it will not {\bf overwrite} grid definition fields already existing in the file with the same grid name. |
---|
431 | |
---|
432 | These routines can be called only by one component process to write the whole grid or by each process holding a part of a grid. In the former case, optional argument {\tt il\_part\_id} is not needed and the arrays (see below) handling the longitudes of the grid points or corners ({\tt lon}, {\tt clon}), the latitudes of the grid points or corners ({\tt lat}, {\tt clat}), the masks ({\tt mask}), fracs ({\tt frac}), and areas ({\tt area}) of the grid cells need to cover the whole grid; in the later case, the {\tt il\_part\_id} returned by {\tt oasis\_def\_partition} needs to be provided as input argument and the arrays need to cover only the local partition of the grid. |
---|
433 | |
---|
434 | The field names in the {\em grids.nc}, {\em masks.nc}, and {\em areas.nc} follow a well-defined convention. The fields are normally two-dimensional, and each field name consists of the gridname followed by a string that identifies the field. For instance, the center latitudes for the grid torc will be called torc.lat and the center longitudes will be called torc.lon in the netcdf file. The {\em grids.nc} file contains the center latitudes (.lat) and longitudes (.lat) as well as the corner latitudes (.cla) and corner longitudes (.clo). The corner fields have a third dimension associated with the number of corners per gridcell. The {\em area.nc} file constains the area field (.srf). The {\em masks.nc} file contains the mask (.msk) and frac (.frc) fields. |
---|
435 | |
---|
436 | \begin{itemize} |
---|
437 | |
---|
438 | \item {\tt CALL oasis\_start\_grids\_writing (flag)} or |
---|
439 | \item {\tt CALL prism\_start\_grids\_writing (flag)} |
---|
440 | \begin{itemize} |
---|
441 | \item {\tt flag [INTEGER; OUT]}: always 1 |
---|
442 | \end{itemize} |
---|
443 | Must be called to start the grid writing process. |
---|
444 | |
---|
445 | \vspace{0.2cm} |
---|
446 | \item {\tt CALL oasis\_write\_grid (cgrid, nx\_global, ny\_global, lon, lat, il\_part\_id)} |
---|
447 | \item {\tt CALL prism\_write\_grid (cgrid, nx\_global, ny\_global, lon, lat, il\_part\_id)} |
---|
448 | |
---|
449 | \begin{itemize} |
---|
450 | \item {\tt cgrid [CHARACTER; IN]}: grid name prefix (see |
---|
451 | \ref{subsec_namcouplesecond} and \ref{subsec_griddata}); maximum length of 64 characters (4 are usually used for historical reasons) |
---|
452 | \item {\tt nx\_global [INTEGER; IN]} : first dimension of the global grid |
---|
453 | \item {\tt ny\_global [INTEGER; IN]} : second dimension of the global grid ({\tt =1} if the grid is expressed as a 1D vector) |
---|
454 | \item {\tt lon [REAL, DIMENSION(nx,ny); IN]} : single or double real array of longitudes covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition (degrees East). |
---|
455 | \item {\tt lat [REAL, DIMENSION(nx,ny); IN]} : single or double real array of latitudes covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition (degrees North) |
---|
456 | \item {\tt il\_part\_id [INTEGER, OPTIONAL; IN]}: partition ID returned by {\tt oasis\_def\_partition}, see \ref{subsubsec_Partition}; needed if each component task holding a part of a decomposed grid writes its own part of the grid. |
---|
457 | \end{itemize} |
---|
458 | |
---|
459 | Writes the component grid longitudes and latitudes. Longitudes must be |
---|
460 | given in degrees East in the interval -360.0 to 720.0. Latitudes |
---|
461 | must be given in degrees North in the interval -90.0 to 90.0. Note |
---|
462 | that if some grid points overlap, it is recommended to define those |
---|
463 | points with the same number (e.g. 90.0 for both, not 450.0 for one |
---|
464 | and 90.0 for the other) to ensure automatic detection of overlap by |
---|
465 | OASIS3-MCT (which is essential to have a correct conservative |
---|
466 | remapping \texttt{SCRIPR/CONSERV}, see section \ref{subsec_interp}). |
---|
467 | |
---|
468 | \vspace{0.2cm} |
---|
469 | \item {\tt CALL oasis\_write\_corner (cgrid, nx\_global, ny\_global, nc, clon, clat, il\_part\_id))} |
---|
470 | \item {\tt CALL prism\_write\_corner (cgrid, nx\_global, ny\_global, nc, clon, clat, il\_part\_id))} |
---|
471 | |
---|
472 | \begin{itemize} |
---|
473 | \item {\tt cgrid }, {\tt nx\_global }, {\tt ny\_global }, {\tt il\_part\_id }: as for {\tt oasis\_write\_grid} |
---|
474 | |
---|
475 | \item {\tt nc [INTEGER; IN]} : number of corners per grid cell (can be any number) |
---|
476 | \item {\tt clon [REAL, DIMENSION (nx,ny,nc);IN]} : single or double real array of corner |
---|
477 | longitudes covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition (in degrees\_East) |
---|
478 | \item {\tt clat [REAL, DIMENSION (nx,ny,nc);IN]} : single or double real array of corner |
---|
479 | latitudes covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition (in degrees\_North) |
---|
480 | \end{itemize} |
---|
481 | |
---|
482 | Writes the grid cell corner longitudes and latitudes |
---|
483 | (counterclockwise sense). Longitudes must be given in degrees East |
---|
484 | in the interval -360.0 to 720.0. Latitudes must be given in degrees |
---|
485 | North in the interval -90.0 to 90.0. Note also that cells larger |
---|
486 | than 180.0 degrees in longitude are not supported. Writing of |
---|
487 | corners is optional as corner information is needed only for {\tt |
---|
488 | SCRIPR/CONSERV} (see section \ref{subsec_interp}). If called, |
---|
489 | needs to be called after {\tt oasis/prism\_write\_grid}. |
---|
490 | |
---|
491 | \vspace{0.2cm} |
---|
492 | \item {\tt CALL oasis\_write\_mask (cgrid, nx\_global, ny\_global, mask, il\_part\_id, companion)} |
---|
493 | \item {\tt CALL prism\_write\_mask (cgrid, nx\_global, ny\_global, mask, il\_part\_id, companion)} |
---|
494 | |
---|
495 | \begin{itemize} |
---|
496 | \item {\tt cgrid }, {\tt nx\_global }, {\tt ny\_global }, {\tt il\_part\_id }: as for {\tt oasis\_write\_grid} |
---|
497 | \item {\tt mask [INTEGER, DIMENSION(nx,ny) ;IN]} : mask array covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition. Be careful about the OASIS historical convention (!): 0 = not masked (active), 1 = masked (not active). |
---|
498 | \item {\tt companion [CHARACTER ;IN; OPTIONAL]} : the character string value associated with the mask field attribute ``coherent\_with\_grid''. This will be written to the {\em masks.nc} netcdf file with the mask field. It is purely informational and used in cases where the mask field is derived from or consistent with another grid. |
---|
499 | \end{itemize} |
---|
500 | Writes the component grid mask. The mask field should be consistent with the frac field and will define the 0/1 mask of the grid cell. The mask field is used by both the {\tt SCRIPR} map generation function and in the {\tt CONSERV} operations if defined. The mask field is written to the {\em masks.nc} file. |
---|
501 | |
---|
502 | \vspace{0.2cm} |
---|
503 | \item {\tt CALL oasis\_write\_frac (cgrid, nx\_global, ny\_global, frac, il\_part\_id, companion)} |
---|
504 | \item {\tt CALL prism\_write\_frac (cgrid, nx\_global, ny\_global, frac, il\_part\_id, companion)} |
---|
505 | |
---|
506 | \begin{itemize} |
---|
507 | \item {\tt cgrid }, {\tt nx\_global }, {\tt ny\_global }, {\tt il\_part\_id }: as for {\tt oasis\_write\_grid} |
---|
508 | \item {\tt frac [REAL, DIMENSION(nx,ny) ;IN]} : single or double real frac array covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition. |
---|
509 | \item {\tt companion [CHARACTER ;IN; OPTIONAL]} : the character string value associated with the frac field attribute ``coherent\_with\_grid''. This will be written to the {\em masks.nc} netcdf file with the fraction field. It is purely informational and used in cases where the frac field is derived from or consistent with another grid. |
---|
510 | \end{itemize} |
---|
511 | Writes the component grid cell fractions. This should be consistent with the mask field and defines the fraction of the grid cell that is active (i.e. not masked). The fraction field is only used in the {\tt CONSERV} operations. Either the mask or fractions must be defined for that operation. If both are defined, they must be consistent; OASIS3-MCT will abort if they are not coherent or if both are missing. Note that by OASIS conventions for the mask, a gridcell with mask=0 (active) should have a fractions greater than 0 and a gridcell with mask=1 (inactive) should have a fractions equal to 0. The fraction field is written to the {\em masks.nc} file. |
---|
512 | |
---|
513 | \vspace{0.2cm} |
---|
514 | \item {\tt CALL oasis\_write\_area (cgrid, nx\_global, ny\_global, area, il\_part\_id)} |
---|
515 | \item {\tt CALL prism\_write\_area (cgrid, nx\_global, ny\_global, area, il\_part\_id)} |
---|
516 | |
---|
517 | \begin{itemize} |
---|
518 | \item {\tt cgrid }, {\tt nx\_global }, {\tt ny\_global }, {\tt il\_part\_id }: as for {\tt oasis\_write\_grid} |
---|
519 | \item {\tt area [REAL, DIMENSION(nx,ny); IN]} : single or double real array of grid cell |
---|
520 | areas covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition |
---|
521 | \end{itemize} |
---|
522 | Writes of the component grid cell areas. Needed for some {\tt SCRIPR} options and for the {\tt CONSERV} |
---|
523 | operation (see section \ref{subsec_cooking}). The area field is written to the {\em areas.nc} file. |
---|
524 | The surfaces may be given in any units but they must be the same on the source and target sides; furthermore they must be in square radians if the True Area (TR) correction is activated, see section 4.3. |
---|
525 | |
---|
526 | \vspace{0.2cm} |
---|
527 | \item {\tt CALL oasis\_write\_angle (cgrid, nx\_global, ny\_global, angle, il\_part\_id)} |
---|
528 | \item {\tt CALL prism\_write\_angle (cgrid, nx\_global, ny\_global, angle, il\_part\_id)} |
---|
529 | |
---|
530 | \begin{itemize} |
---|
531 | \item {\tt cgrid }, {\tt nx\_global }, {\tt ny\_global }, {\tt il\_part\_id }: as for {\tt oasis\_write\_grid} |
---|
532 | \item {\tt angle [REAL, DIMENSION(nx,ny); IN]} : single or double real array of grid cell |
---|
533 | angles covering the whole grid ({\tt nx=nx\_global}, {\tt ny=ny\_global}) or only the local partition |
---|
534 | \end{itemize} |
---|
535 | Writes of the component grid cell angles. The angle field is written to the {\em grids.nc} file. This field does not play a role in OASIS3-MCT implementation and is never needed. |
---|
536 | |
---|
537 | |
---|
538 | \vspace{0.2cm} |
---|
539 | \item {\tt CALL prism\_terminate\_grids\_writing()} or |
---|
540 | \item {\tt CALL oasis\_terminate\_grids\_writing()} |
---|
541 | |
---|
542 | \end{itemize} |
---|
543 | |
---|
544 | The creation of the different grid data files is completed in the routine |
---|
545 | oasis\_enddef. |
---|
546 | |
---|
547 | \subsection{Coupling field declaration} |
---|
548 | \label{subsubsec_Declaration} |
---|
549 | |
---|
550 | All processes of a component that send or receive a coupling field, or a part of it, needs to declare the coupling field. |
---|
551 | |
---|
552 | Processes not implied in the |
---|
553 | coupling do not have to call this routine at all (for backward |
---|
554 | compatibility with OASIS3-MCT\_2.0, they may still call it with any {\tt name} and {\tt il\_part\_id}). |
---|
555 | |
---|
556 | \begin{itemize} |
---|
557 | |
---|
558 | \item {\tt CALL oasis\_def\_var (var\_id, name, il\_part\_id, |
---|
559 | var\_nodims, kinout, \newline var\_type, |
---|
560 | kinfo)} or |
---|
561 | |
---|
562 | \item {\tt CALL oasis\_def\_var (var\_id, name, il\_part\_id, |
---|
563 | var\_nodims, kinout, \newline var\_actual\_shape, var\_type, |
---|
564 | kinfo)} or |
---|
565 | |
---|
566 | \item {\tt CALL prism\_def\_var\_proto(var\_id, name, il\_part\_id, |
---|
567 | var\_nodims, kinout, var\_type, kinfo)} or |
---|
568 | |
---|
569 | \item {\tt CALL prism\_def\_var\_proto(var\_id, name, il\_part\_id, |
---|
570 | var\_nodims, kinout, var\_actual\_shape, var\_type, kinfo)} |
---|
571 | |
---|
572 | \begin{itemize} |
---|
573 | \item {\tt var\_id [INTEGER; OUT]}: coupling field ID. Note that all |
---|
574 | coupling fields appearing in the {\it namcouple} must be defined with |
---|
575 | a call to {\tt oasis\_def\_var}; not doing so would lead to an abort. |
---|
576 | But all fields defined with a call to {\tt oasis\_def\_var} must not necessarily |
---|
577 | appear in the {\it namcouple}. If a field does not appear in the {\it namcouple}, |
---|
578 | the {\tt var\_id} returned by the {\tt oasis\_def\_var} will be equal to -1; |
---|
579 | the value of the {\tt var\_id} should be tested and the corresponding |
---|
580 | {\tt oasis\_put} and {\tt oasis\_get} should not be called if {\tt var\_id} |
---|
581 | equals -1. These constraints are imposed to avoid that a typo in the {\it namcouple} |
---|
582 | would lead to coupling exchanges not corresponding to what the user intends to activate. |
---|
583 | \item {\tt name [CHARACTER; IN]}: field symbolic name (as in the |
---|
584 | {\it namcouple}); maximum length of 80 characters |
---|
585 | \item {\tt il\_part\_id [INTEGER; IN]}: partition ID returned from {\tt oasis\_def\_partition} (see section |
---|
586 | \ref{subsubsec_Partition}) |
---|
587 | \item {\tt var\_nodims [INTEGER, DIMENSION(2); IN]}: is an integer array of size two. |
---|
588 | The first element, var\_nodims(1), is not used anymore in OASIS3-MCT, so |
---|
589 | its value can be anything; The second element, var\_nodims(2), |
---|
590 | is the number of fields in a bundle (this will be 1 for unbundled |
---|
591 | fields or greater than 1 for fields that are bundled; note that |
---|
592 | if var\_nodims(2)=0, it will be automatically reset to 1 in the |
---|
593 | routine, to ensure backward compatibility). |
---|
594 | \item {\tt kinout [INTEGER; IN]}: {\tt OASIS\_In} or {\tt PRISM\_In} |
---|
595 | (i.e. = 21) for fields received by the component; {\tt OASIS\_Out}, |
---|
596 | {\tt PRISM\_Out} (i.e. = 20) for fields sent by the component |
---|
597 | \footnote{Parameters OASIS\_In, PRISM\_In, OASIS\_Out, PRISM\_Out |
---|
598 | are defined in |
---|
599 | oasis3-mct/lib/psmile/src/mod\_oasis\_parameters.F90}. |
---|
600 | \item {\tt var\_actual\_shape [INTEGER, DIMENSION(2*id\_var\_nodims(1)), IN]}: |
---|
601 | is not used anymore. The interface has recently |
---|
602 | been overloaded, and this argument is no longer required. But |
---|
603 | for backwards compatibility, it can still be passed; if so, it has to be a vector of integers of any length (for simplicity we advise to pass a vector of length 1). |
---|
604 | \item {\tt var\_type [INTEGER; IN]}: type of coupling field array; |
---|
605 | put {\tt OASIS\_Real} or {\tt PRISM\_Real} (i.e. = 4) for single |
---|
606 | or double precision real arrays. All coupling data is treated as |
---|
607 | double precision in the coupling layer, but conversion to or from |
---|
608 | single precision data is supported in the interface. |
---|
609 | \item {\tt kinfo [INTEGER; OUT]}: returned error code. |
---|
610 | \end{itemize} |
---|
611 | \end{itemize} |
---|
612 | % {coupling field declaration} |
---|
613 | |
---|
614 | \subsection{End of definition phase} |
---|
615 | \label{subsubsec_Endofdefinition} |
---|
616 | All processes of components at least partly involved in the coupling (e.g. {\tt comp3} in figure |
---|
617 | \ref{Fig_coupling_layouts_b}) have to close the definition phase. Different configurations of components and corresponding use of {\tt oasis\_enddef} are described in section \ref{sec_deploy} and on figures \ref{Fig_coupling_layouts_a} and \ref{Fig_coupling_layouts_b}. |
---|
618 | \begin{itemize} |
---|
619 | \item {\tt CALL oasis\_enddef (kinfo)} |
---|
620 | \item {\tt CALL prism\_enddef\_proto(kinfo)} |
---|
621 | \begin{itemize} |
---|
622 | \item kinfo [INTEGER; OUT]: returned error code. |
---|
623 | \end{itemize} |
---|
624 | \end{itemize} |
---|
625 | |
---|
626 | % {End of definition phase} |
---|
627 | |
---|
628 | \subsection{Sending ``put'' and receiving ``get'' actions} |
---|
629 | \label{subsubsec_sendingreceiving} |
---|
630 | |
---|
631 | This section describes how to send (put) and receive (get) fields through |
---|
632 | the coupling interface. This interface supports several ranks and |
---|
633 | types of coupling fields. First, the fields passed into the interface can be |
---|
634 | 4 byte or 8 byte reals. The field decomposition must be |
---|
635 | consistent with the decomposition defined in the grid partition (see \ref{subsubsec_Partition})\footnote{But the decomposition of each field can be either one |
---|
636 | dimensional or two dimensional and does not |
---|
637 | have to match the rank of the grid partition.} Third, the fields |
---|
638 | can be bundled, i.e. have an extra (non-spatial) dimension like for a field covering different ice categories. The bundled dimension is always the last dimension in any |
---|
639 | field passed into the get and put routines. And the size of the bundle dimension |
---|
640 | must match the value defined for the variable in var\_nodims(2) in the |
---|
641 | {\tt oasis\_def\_var} interface (see section \ref{subsubsec_Declaration}). |
---|
642 | |
---|
643 | So in general, the fields passed into the get and put interface can have rank |
---|
644 | 1, 2, or 3 and include the following possible options where fld can be a 4 |
---|
645 | byte or 8 byte real array. |
---|
646 | |
---|
647 | \begin{itemize} |
---|
648 | \item 1D, fld(:) = an single, unbundled field of decomposition rank 1. |
---|
649 | \item 2D, fld(:,:) = a single, unbundled field of decomposition rank 2. |
---|
650 | \item 1D bundled, fld(:,:) = a bundled set of fields of decomposition rank 1. |
---|
651 | The size of the second dimension must equal the number of fields in the |
---|
652 | bundle, defined by var\_nodims(2) in the {\tt oasis\_def\_var} interface. |
---|
653 | \item 2D bundled, fld(:,:,:) = a bundled set of fields of decomposition rank 2. |
---|
654 | The size of the third dimension must equal the number of fields in the |
---|
655 | bundle, defined by var\_nodims(2) in the {\tt oasis\_def\_var} interface. |
---|
656 | \end{itemize} |
---|
657 | |
---|
658 | %With bundled fields, it is important that the number of fields in the bundle match |
---|
659 | %in the two models being coupled. This requires that the var\_nodims(2) values |
---|
660 | %in the send and receive model match the bundle dimension of that bundled coupling field. |
---|
661 | Different bundled fields |
---|
662 | can have different numbers of fields, but for a given bundled field, the |
---|
663 | number of fields must match on the send and receive side. This is explicitly |
---|
664 | checked within the coupling layer and will lead to an abort if not done correctly. |
---|
665 | It is possible to define a 1D bundled or 2D bundled field with a bundle dimension of 1, i.e. for a bundle that contains only one single field. |
---|
666 | |
---|
667 | Finally, the bundled field option can be used to |
---|
668 | bundle together multi-level variables, multiple related fields, and other types |
---|
669 | of fields. The fields must share a common partition and common namcouple settings (e.g. interpolation) |
---|
670 | to be bundled. While this is a useful feature for multi-level fields, {\bf this does not mean |
---|
671 | that 3D interpolation is supported}. |
---|
672 | Each field in the bundle is |
---|
673 | treated internally as a separate field in the coupling layer without |
---|
674 | any information about the relationship between the fields in the bundle. In fact, |
---|
675 | the bundled field variables are internally renamed and a field number is appended |
---|
676 | to the variable name to keep track of the distinct fields in the bundle. That |
---|
677 | updated variable name will appear in restart and output files. |
---|
678 | |
---|
679 | |
---|
680 | \subsubsection{Sending a coupling (or I/O) field or writing a coupling restart file} |
---|
681 | \label{prismput} |
---|
682 | |
---|
683 | In the component time step loop, each process sends its part of the |
---|
684 | coupling (or I/O) field. |
---|
685 | |
---|
686 | \begin{itemize} |
---|
687 | \item {\tt CALL oasis\_put (var\_id, date, fld1, info, fld2, fld3, |
---|
688 | fld4, fld5, write\_restart)} |
---|
689 | \item {\tt CALL prism\_put\_proto(var\_id, date, fld1, info, fld2, |
---|
690 | fld3, fld4, fld5, write\_restart)} |
---|
691 | \begin{itemize} |
---|
692 | \item {\tt var\_id [INTEGER; IN]}: field ID (returned from corresponding {\tt |
---|
693 | oasis\_def\_var}, see section \ref{subsubsec_Declaration}) |
---|
694 | \item {\tt date [INTEGER; IN]}: number of seconds (or any other time |
---|
695 | units as long as the same are used in all components and in the {\it |
---|
696 | namcouple}) at the time of the call (by convention at the |
---|
697 | beginning of the timestep) |
---|
698 | \item {\tt fld1 [REAL, IN]}: coupling (or I/O) field array; can be |
---|
699 | 1D, 2D, bundled 1D, or bundled 2D, see baove. |
---|
700 | \item {\tt info [INTEGER; OUT]}: returned info code: |
---|
701 | \begin{itemize} |
---|
702 | \item {\tt OASIS\_Sent} (=4) if the field was sent to another component |
---|
703 | \item {\tt OASIS\_LocTrans} (=5) if the field was only used in a time |
---|
704 | transformation (not sent, not output) |
---|
705 | \item {\tt OASIS\_ToRest} (=6) if the field was written to a restart |
---|
706 | file only |
---|
707 | \item {\tt OASIS\_Output} (=7) if the field was written to an output |
---|
708 | file only |
---|
709 | \item {\tt OASIS\_SentOut} (=8) if the field was both written to an |
---|
710 | output file and sent to another component |
---|
711 | \item {\tt OASIS\_ToRestOut} (=9) if the field was written both to a |
---|
712 | restart file and to an output file. |
---|
713 | \item {\tt OASIS\_WaitGroup} (=14) if the field was not sent because it is part of a group. |
---|
714 | It will be sent only when the {\tt oasis\_put} of the last field in the group will be called; however, the field is buffered and therefore the field array can be modified in the component code when returning from the oasis\_put call. |
---|
715 | \item {\tt OASIS\_Ok} (=0) otherwise and no error occurred. |
---|
716 | \end{itemize} |
---|
717 | \item {\tt fld2 [REAL, IN, OPTIONAL]}: optional $2^{nd}$ coupling |
---|
718 | field array; can be 1D, 2D, bundled 1D, or bundled 2D. Rank and size |
---|
719 | must match {\tt fld1}. |
---|
720 | \item {\tt fld3 [REAL, IN, OPTIONAL]}: optional $3^{rd}$ coupling |
---|
721 | field array; can be 1D, 2D, bundled 1D, or bundled 2D. Rank and size |
---|
722 | must match {\tt fld1}. |
---|
723 | \item {\tt fld4 [REAL, IN, OPTIONAL]}: optional $4^{th}$ coupling |
---|
724 | field array; can be 1D, 2D, bundled 1D, or bundled 2D. Rank and size |
---|
725 | must match {\tt fld1}. |
---|
726 | \item {\tt fld5 [REAL, IN, OPTIONAL]}: optional $5^{th}$ coupling |
---|
727 | field array; can be 1D, 2D, bundled 1D, or bundled 2D. Rank and size |
---|
728 | must match {\tt fld1}. |
---|
729 | \item {\tt write\_restart [LOGICAL, IN, OPTIONAL]}: optional argument to write an |
---|
730 | intermediate restart file associated with the variable {\tt |
---|
731 | var\_id} at the current timestep (see below). |
---|
732 | \end{itemize} |
---|
733 | \end{itemize} |
---|
734 | |
---|
735 | To ensure a proper use of the {\tt oasis\_put}, one has to take care |
---|
736 | of the following aspects: |
---|
737 | |
---|
738 | \begin{itemize} |
---|
739 | |
---|
740 | \item A $2^{nd}$, $3^{rd}$, $4^{th}$ and $5^{th}$ source field can be |
---|
741 | passed as optional arguments. If so, the $2^{nd}$, $3^{rd}$, |
---|
742 | $4^{th}$ and $5^{th}$ set of weights present in the remapping file |
---|
743 | will be applied, respectively (see section \ref{subsec_mapdata} for |
---|
744 | the remapping file format). This will be used for example for the {\tt |
---|
745 | SCRIPR/BICUBIC} remapping for which a $1^{st}$, $2^{nd}$, |
---|
746 | $3^{rd}$, $4^{th}$ set of weights should be respectively applied to |
---|
747 | the field value, its gradient in the first dimension, its gradient |
---|
748 | in the second dimension, and its cross-gradient in that order. |
---|
749 | |
---|
750 | This will be used also for the CONSERV/SECOND for which a 1st, 2nd, 3rd |
---|
751 | set of weights should be respectively applied to the field value, its |
---|
752 | gradient with respect to the latitude ($\theta$) $\frac{\delta f}{\delta \theta}$ |
---|
753 | and its gradient with respect to the longitude ($\phi$) $\frac{1}{cos \theta}\frac{\delta f}{\delta \phi}$ |
---|
754 | in that order. |
---|
755 | |
---|
756 | Bicubic and higher order |
---|
757 | remapping are therefore supported given that the higher order fields |
---|
758 | are provided at each time step as {\tt oasis\_put} arguments. Note |
---|
759 | that if {\tt fld3}, or {\tt fld4}, or {\tt fld5} are passed, {\tt fld2}, or {\tt fld3} and |
---|
760 | {\tt fld2}, or {\tt fld4} and {\tt fld3} and {\tt fld2} must also be passed respectively. |
---|
761 | |
---|
762 | \item {\bf Note that from OASIS3-MCT\_4.0 onwards, |
---|
763 | the number of weights in the remapping file and the number of fields in the coupling restart file |
---|
764 | (when such a file is needed) must strictly match the number of source fields passed to the |
---|
765 | oasis\_put .} |
---|
766 | |
---|
767 | %\item Trying to send with {\tt oasis\_put} a field declared with a |
---|
768 | % {\tt oasis\_def\_var} but not defined in the configuration file {\it |
---|
769 | % namcouple} will lead to an abort. In this case, the field ID |
---|
770 | % returned by the {\tt oasis\_def\_var} is equal to -1 and the |
---|
771 | % corresponding {\tt oasis\_put} should not be called. |
---|
772 | |
---|
773 | \item This routine may be called by the component at each timestep. The |
---|
774 | convention for the {\tt date} argument is to indicate the time at |
---|
775 | the beginning of the timestep. The sending is actually performed |
---|
776 | if the time obtained by adding the field lag ({\tt LAG} in the |
---|
777 | {\em namcouple}, if any, with {\tt LAG=0} by default) to the {\tt date} corresponds to a time at which it |
---|
778 | should be activated, given the coupling or I/O period indicated by |
---|
779 | the user in the {\it namcouple} (see section \ref{sec_namcouple}). |
---|
780 | |
---|
781 | \item By convention, the first coupling |
---|
782 | of a run occurs at {\tt date=0} and the final coupling occurs |
---|
783 | at {\tt date = runtime-cpl\_period}, where {\tt runtime} is the total time of |
---|
784 | the run and {\tt cpl\_period} is the coupling period of the field indicated by |
---|
785 | the user in the {\it namcouple} (see section \ref{sec_namcouple}). |
---|
786 | |
---|
787 | \item For a coupling |
---|
788 | field with a positive lag, the coupling restart file (see section |
---|
789 | \ref{subsec_restartdata}) is automatically overwritten by the {\tt |
---|
790 | oasis\_put} when the {\tt date+LAG=runtime}. |
---|
791 | |
---|
792 | % \item A field will not be sent at all if its coupling (or I/O) |
---|
793 | % period indicated in the {\it namcouple} is greater than the |
---|
794 | % total run time. |
---|
795 | |
---|
796 | \item The total run time should match an integer number of coupling |
---|
797 | periods. |
---|
798 | |
---|
799 | \item If a local time transformation is indicated for the field by the |
---|
800 | user in the {\it namcouple} (INSTANT, AVERAGE, ACCUMUL, T\_MIN or |
---|
801 | T\_MAX, see section \ref{sec_transformations}), it is automatically |
---|
802 | performed and the resulting field is finally sent at the coupling or |
---|
803 | I/O frequency. For non-instant transformations, partially |
---|
804 | transformed fields will be written to the restart file at the end of |
---|
805 | the run for use on the next component startup, when needed. |
---|
806 | |
---|
807 | \item A coupling field sent by a source component can be |
---|
808 | associated with more than one target field and component, if specified |
---|
809 | as so with different entries in the {\it namcouple} configuration |
---|
810 | file. In that case, the source component needs to send the field only |
---|
811 | once and the corresponding data will arrive at multiple targets as |
---|
812 | specified in the {\it namcouple}. Different coupling frequencies and |
---|
813 | transformations are allowed for different coupling exchanges of the |
---|
814 | same field. If coupling restart files are required (either if a {\tt |
---|
815 | LAG} or if a {\tt LOCTRANS} transformation is specified), it is |
---|
816 | mandatory to specify different files for the different fields. |
---|
817 | |
---|
818 | \item Trying to send with {\tt oasis\_put} a field declared with a {\tt |
---|
819 | oasis\_def\_var} but not defined in the configuration file {\it |
---|
820 | namcouple} will lead to an abort. When a field is not defined in the {\it namcouple}, the field ID |
---|
821 | returned by the {\tt oasis\_def\_var} is equal to -1 and the |
---|
822 | corresponding {\tt oasis\_put} should not be called. |
---|
823 | |
---|
824 | \item Support to couple multiple fields via a single communication. |
---|
825 | This is supported through colon delimited field lists in the namcouple (see \ref{subsubsec_secondEXPORTED}). |
---|
826 | All fields will use the namcouple settings for that entry. In the component |
---|
827 | model codes, these fields are still sent ({\bf âputâ}) one at a time. Inside |
---|
828 | OASIS3-MCT, the fields are stored and a single mapping and send instruction is executed |
---|
829 | for all fields. This is useful in cases where multiple fields have the same coupling transformations |
---|
830 | and to reduce communication costs by aggregating multiple fields into a single communication. |
---|
831 | |
---|
832 | This option does not put any constraint |
---|
833 | on the order of the related {\tt oasis\_put} and {\tt oasis\_get} in the codes. |
---|
834 | |
---|
835 | As they appear in one single entry line, these fields must share the same coupling restart file |
---|
836 | but this restart file may contain other fields. |
---|
837 | |
---|
838 | \item The optional argument, {\tt write\_restart}, in the {\tt oasis\_put} routine is {\bf false} by default. |
---|
839 | If a user sets that argument to true, a restart file will be written for that field {\bf only for that timestep}. The {\tt write\_restart} |
---|
840 | will just save the data that exists at the time of the call, taking into account lags and LOCTRANS operations. In |
---|
841 | cases where multiple fields are coupled as a single operation in the model (indicated via a list of colon delimited |
---|
842 | fields in the {\it namcouple}, see \ref{subsubsec_secondEXPORTED}), users are encouraged to specify |
---|
843 | the {\tt write\_restart} flag on ALL {\tt oasis\_put} calls at a given |
---|
844 | time for this set of fields. |
---|
845 | Intermediate restarts will be created with a timestamp prepended to |
---|
846 | their filename, like TA000003600\_rst4.nc or TC000014400\_rst4.nc. |
---|
847 | A restart file that starts with TA will be a restart file associated |
---|
848 | with LOCTRANS operations. A restart |
---|
849 | file that starts with TC will be a restart file associated with |
---|
850 | coupling operations. The 9 digit timestamp in |
---|
851 | the filename is the date in seconds at the time of the oasis\_put |
---|
852 | call. The restart filename (ie. rst4.nc) |
---|
853 | defined in the namcouple for variables will be used to generate a filename for intermediate restart files. |
---|
854 | \end{itemize} |
---|
855 | |
---|
856 | \subsubsection{Receiving a coupling (or I/O) field} |
---|
857 | |
---|
858 | In the component time stepping loop, each process receives its part of the |
---|
859 | coupling field. |
---|
860 | |
---|
861 | \begin{itemize} |
---|
862 | |
---|
863 | \item {\tt CALL oasis\_get (var\_id, date, fld, info)} |
---|
864 | \item {\tt CALL prism\_get\_proto(var\_id, date, fld, info)} |
---|
865 | \begin{itemize} |
---|
866 | \item {\tt var\_id [INTEGER; IN]}: field ID (returned by the corresponding |
---|
867 | {\tt oasis\_def\_var}) |
---|
868 | \item {\tt date [INTEGER; IN]}: number of seconds (or any other time |
---|
869 | units as long as the same are used in all components and in the {\it |
---|
870 | namcouple}) at the time of the call (by convention at the |
---|
871 | beginning of the timestep) |
---|
872 | \item {\tt fld [REAL, OUT]}: I/O or coupling field array; |
---|
873 | can be 1D, 2D, bundled 1D, or bundled 2D. |
---|
874 | \item {\tt info [INTEGER; OUT]}: returned info code: |
---|
875 | \begin{itemize} |
---|
876 | \item OASIS\_Recvd(=3) if the field was received from another |
---|
877 | component |
---|
878 | \item OASIS\_FromRest (=10) if the field was read from a restart |
---|
879 | file only |
---|
880 | \item OASIS\_Input (=11) if the field was read from an input file |
---|
881 | only |
---|
882 | \item OASIS\_RecvOut (=12) if the field was both received from |
---|
883 | another component and written to an output file |
---|
884 | \item OASIS\_FromRestOut (=13) if the field was both read from a |
---|
885 | restart file and written to an output file |
---|
886 | \item OASIS\_Ok (=0) otherwise and no error occurred. |
---|
887 | \end{itemize} |
---|
888 | \end{itemize} |
---|
889 | \end{itemize} |
---|
890 | |
---|
891 | To ensure a proper use of the {\tt oasis\_get}, one has to take care of the following aspects: |
---|
892 | |
---|
893 | \begin{itemize} |
---|
894 | |
---|
895 | \item This routine may be called by the component at each timestep. The {\tt |
---|
896 | date} argument is automatically analysed and the receiving action is |
---|
897 | actually performed only if {\tt date} corresponds to a time for which |
---|
898 | it should be activated, given the period indicated by the user in the |
---|
899 | {\it namcouple}. An exchange at the beginning of the run at time=0 is |
---|
900 | expected. |
---|
901 | |
---|
902 | \item Trying to receive with {\tt oasis\_get} a field declared with a {\tt |
---|
903 | oasis\_def\_var} but not defined in the configuration file {\it |
---|
904 | namcouple} will lead to an abort. In this case, the field ID |
---|
905 | returned by the {\tt oasis\_def\_var} is equal to -1 and the |
---|
906 | corresponding {\tt oasis\_get} should not be called. |
---|
907 | |
---|
908 | \item If a coupling field has a positive lag, the coupling field that |
---|
909 | matches the {\tt oasis\_get} at time=0 will come from a coupling |
---|
910 | restart file written by the last active {\tt oasis\_put} of the |
---|
911 | previous run (see section \ref{subsec_lag}). |
---|
912 | |
---|
913 | \item Support to couple multiple fields via a single communication. |
---|
914 | This is supported through colon delimited field lists in the namcouple (see \ref{subsubsec_secondEXPORTED}). |
---|
915 | All fields will use the namcouple settings for that entry. In the component |
---|
916 | model codes, these fields are still received (via an {\tt oasis\_get}) one at a time. Inside |
---|
917 | OASIS3-MCT, the fields are stored and a single mapping and receive instruction is executed |
---|
918 | for all fields. This is useful in cases where multiple fields have the same coupling transformations |
---|
919 | and to reduce communication costs by aggregating multiple fields into a single communication. If a |
---|
920 | LOCTRANS transformation is needed for these multiple fields, it is necessary to define a restart file |
---|
921 | for these multiple fields. |
---|
922 | \end{itemize} |
---|
923 | |
---|
924 | \subsection{Termination} |
---|
925 | \label{subsubsec_Termination} |
---|
926 | |
---|
927 | \begin{itemize} |
---|
928 | |
---|
929 | \item {\tt CALL oasis\_terminate (kinfo)} |
---|
930 | \item {\tt CALL prism\_terminate\_proto(kinfo)} |
---|
931 | \begin{itemize} |
---|
932 | \item {\tt kinfo [INTEGER; OUT]}: returned error code. |
---|
933 | \end{itemize} |
---|
934 | All processes of components at least partly involved in the coupling (e.g. {\tt comp3} in figure |
---|
935 | \ref{Fig_coupling_layouts_b}) have to terminate the coupling by |
---|
936 | calling this routine\footnote{If the process called {\tt MPI\_Init} |
---|
937 | (before calling {\tt oasis\_init\_comp}), it must also call {\tt |
---|
938 | MPI\_Finalize} explicitly, but only after calling {\tt |
---|
939 | oasis\_terminate\_proto}.}(normal termination). Different configurations of components and corresponding use of {\tt oasis\_terminate} are described in section \ref{sec_deploy} and on figures \ref{Fig_coupling_layouts_a} and \ref{Fig_coupling_layouts_b}. |
---|
940 | |
---|
941 | |
---|
942 | |
---|
943 | \end{itemize} |
---|
944 | |
---|
945 | % {Termination} |
---|
946 | |
---|
947 | \subsection{Auxiliary routines} |
---|
948 | \label{subsubsec_auxroutines} |
---|
949 | |
---|
950 | The following auxiliary routines are currently available. |
---|
951 | |
---|
952 | \begin{itemize} |
---|
953 | \item {\tt CALL oasis\_abort (compid, routine\_name, abort\_message, file, line, rcode)} |
---|
954 | \item {\tt CALL prism\_abort\_proto(compid, routine\_name, |
---|
955 | abort\_message, file, line, rcode)} |
---|
956 | \begin{itemize} |
---|
957 | \item {\tt compid [INTEGER; IN]}: component ID (from {\tt |
---|
958 | oasis\_init\_comp}) |
---|
959 | \item {\tt routine\_name [CHARACTER*; IN]}: name of calling routine |
---|
960 | \item {\tt abort\_message [CHARACTER*; IN]}: message to be written out |
---|
961 | \item {\tt file [CHARACTER*; OPTIONAL; IN]}: file from which oasis\_abort is called from |
---|
962 | \item {\tt line [INTEGER, OPTIONAL; IN]}: line in file from which oasis\_abort is called from |
---|
963 | \item {\tt rcode [INTEGER, OPTIONAL; IN]}: Optional argument. When OASIS |
---|
964 | aborts, it returns rcode if it is present, else it returns 1 |
---|
965 | \end{itemize} |
---|
966 | |
---|
967 | If a process needs to abort voluntarily, it should do so by calling |
---|
968 | {\tt oasis\_abort}. This will ensure a proper termination of all |
---|
969 | processes in the coupled model communicator. This routine writes the |
---|
970 | name of the calling component, the name of the calling routine, and the |
---|
971 | message to the process debug file (see {\tt \$NLOGPRT} in section |
---|
972 | \ref{subsec_namcouplefirst}). This routine cannot be called before |
---|
973 | {\tt oasis\_init\_comp}. |
---|
974 | |
---|
975 | \vspace{0.2cm} |
---|
976 | \item {\tt CALL oasis\_get\_debug(debug, kinfo)} |
---|
977 | \item {\tt CALL prism\_get\_debug(debug, kinfo)} |
---|
978 | \begin{itemize} |
---|
979 | \item {\tt debug [INTEGER; OUT]}: output debug value |
---|
980 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
981 | \end{itemize} |
---|
982 | |
---|
983 | This routine may be called at any time to retrieve the current |
---|
984 | OASIS3-MCT internal debug level (see {\tt \$NLOGPRT} in section |
---|
985 | \ref{subsec_namcouplefirst}). This is useful if the user wants to |
---|
986 | return the original debug value after changing it. |
---|
987 | |
---|
988 | \vspace{0.2cm} |
---|
989 | \item {\tt CALL oasis\_set\_debug(debug, kinfo)} |
---|
990 | \item {\tt CALL prism\_set\_debug(debug, kinfo)} |
---|
991 | \begin{itemize} |
---|
992 | \item {\tt debug [INTEGER; IN]}: input debug value |
---|
993 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
994 | \end{itemize} |
---|
995 | |
---|
996 | This routine may be called at any time to change the debug level in |
---|
997 | OASIS3-MCT. This method allows users to vary the debug level at |
---|
998 | different points in the component integration. |
---|
999 | |
---|
1000 | \vspace{0.2cm} |
---|
1001 | \item {\tt CALL oasis\_get\_intercomm(new\_comm, cdnam, kinfo)} |
---|
1002 | \item {\tt CALL prism\_get\_intercomm(new\_comm, cdnam, kinfo)} |
---|
1003 | \begin{itemize} |
---|
1004 | \item {\tt new\_comm [INTEGER; OUT]}: MPI inter-communicator |
---|
1005 | \item {\tt cdnam [CHARACTER*; IN]}: other component name (i.e. 2nd argument of the call to {\tt oasis\_init\_comp} in that component) |
---|
1006 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
1007 | \end{itemize} |
---|
1008 | |
---|
1009 | This routine sets up an MPI inter-communicator between two components, |
---|
1010 | the local component and the component |
---|
1011 | associated with {\tt cdnam}. This call is collective across the |
---|
1012 | tasks of the two components only. |
---|
1013 | An MPI inter-communicator preserves the rank of the original communicators |
---|
1014 | and does not allow collective communication within the communicator. It |
---|
1015 | provides point to point communication between two non-overlapping MPI groups. |
---|
1016 | This method must be called synchronously across all components involved to |
---|
1017 | minimize the chance of a deadlock, and it should be called only after |
---|
1018 | {\tt oasis\_enddef} is called. |
---|
1019 | See {\tt oasis\_get\_intracomm} below to create an intra-communicator. |
---|
1020 | |
---|
1021 | \vspace{0.2cm} |
---|
1022 | \item {\tt CALL oasis\_get\_intracomm(new\_comm, cdnam, kinfo)} |
---|
1023 | \item {\tt CALL prism\_get\_intracomm(new\_comm, cdnam, kinfo)} |
---|
1024 | \begin{itemize} |
---|
1025 | \item {\tt new\_comm [INTEGER; OUT]}: MPI intra-communicator |
---|
1026 | \item {\tt cdnam [CHARACTER*; IN]}: other component name (i.e. 2nd argument of the call to {\tt oasis\_init\_comp} in that component). This argument is a single string. |
---|
1027 | \item {\tt kinfo [INTEGER; OUT; OPTIONAL]}: returned error code |
---|
1028 | \end{itemize} |
---|
1029 | |
---|
1030 | This routine sets up an MPI intra-communicator between two |
---|
1031 | components, the local component and the component defined by |
---|
1032 | the string {\tt cdnam}. This call is collective |
---|
1033 | across the tasks of the two components creating the intra-communicator only, |
---|
1034 | and it must be called synchronously across all tasks of the two components |
---|
1035 | to minimize the chance of a deadlock. It should be called only after |
---|
1036 | {\tt oasis\_enddef} is called. |
---|
1037 | This method creates a new communicator consisting of a new collective group |
---|
1038 | of tasks with new ranks. |
---|
1039 | This communicator supports collective communications and is |
---|
1040 | more typically used in MPI applications than inter-communicators |
---|
1041 | (see {\tt oasis\_get\_intercomm} above). |
---|
1042 | See also {\tt oasis\_get\_multi\_intracomm} for another method that |
---|
1043 | supports creating an MPI intra-communicator between two or more components. |
---|
1044 | |
---|
1045 | \vspace{0.2cm} |
---|
1046 | \item {\tt CALL oasis\_get\_multi\_intracomm(new\_comm, cdnam, root\_ranks, kinfo)} |
---|
1047 | \item {\tt CALL prism\_get\_multi\_intracomm(new\_comm, cdnam, root\_ranks, kinfo)} |
---|
1048 | \begin{itemize} |
---|
1049 | \item {\tt new\_comm [INTEGER; OUT]}: MPI intra-communicator |
---|
1050 | \item {\tt cdnam [CHARACTER*; IN]}: array of component names (i.e. 2nd argument of the call to {\tt oasis\_init\_comp} in that component). This argument is a 1d array of character strings (i.e. cdnam(:)). |
---|
1051 | \item {\tt root\_ranks [INTEGER; OUT]}: array of root ranks. This argument is a 1d integer array (i.e. root\_ranks(:)) of the same size as {\tt cdnam}. |
---|
1052 | \item {\tt kinfo [INTEGER; OUT]}: returned error code |
---|
1053 | \end{itemize} |
---|
1054 | |
---|
1055 | This routine sets up an MPI intra-communicator between two or more |
---|
1056 | components defined by the component names passed in the {\tt cdnam} array |
---|
1057 | argument. The local model name MUST BE one of the |
---|
1058 | models defined in the {\tt cdnam} array. The component names must |
---|
1059 | be valid names, but empty strings are allowed and ignored. |
---|
1060 | This call is collective |
---|
1061 | across all the tasks of the components defined in {\tt cdnam}, |
---|
1062 | and it must be called synchronously and consistently across all tasks of |
---|
1063 | those components to minimize the chance of a deadlock. It should be called only after |
---|
1064 | {\tt oasis\_enddef} is called. |
---|
1065 | This method creates a new communicator consisting of a new collective group |
---|
1066 | of tasks with new ranks. The root ranks of the individual components relative |
---|
1067 | to the new communicator is output in the {\tt root\_ranks} argument. |
---|
1068 | The size of {\tt cdnam} and {\tt root\_ranks} should be identical, |
---|
1069 | and the values of {\tt root\_ranks} are consistent with the order of {\tt cdnam}.. |
---|
1070 | This communicator supports collective communications and is |
---|
1071 | more typically used in MPI applications than inter-communicators |
---|
1072 | (see {\tt oasis\_get\_intercomm} above). |
---|
1073 | See also {\tt oasis\_get\_intracomm} for another method that |
---|
1074 | supports creating an MPI intra-communicator between two components. |
---|
1075 | |
---|
1076 | \item {\tt CALL oasis\_put\_inquire(var\_id, date, kinfo)} |
---|
1077 | \item {\tt CALL prism\_put\_inquire\_proto(var\_id, date, kinfo)} |
---|
1078 | \begin{itemize} |
---|
1079 | \item {\tt var\_id [INTEGER; IN]}: field ID (from |
---|
1080 | corresponding oasis\_def\_var) |
---|
1081 | \item {\tt date [INTEGER; IN]}: as in {\tt oasis\_put}, number of seconds (or any other time |
---|
1082 | units as long as the same are used in all components and in the {\it |
---|
1083 | namcouple}) in the run at the time of the call |
---|
1084 | \item {\tt kinfo [INTEGER; OUT]}: returned info code |
---|
1085 | \begin{itemize} |
---|
1086 | \item OASIS\_Sent(=4) if the field would be sent to another component |
---|
1087 | \item OASIS\_LocTrans (=5) if the field would be only used in a time |
---|
1088 | transformation (not sent, not output) |
---|
1089 | \item OASIS\_ToRest (=6) if the field would be written to a restart |
---|
1090 | file only |
---|
1091 | \item OASIS\_Output (=7) if the field would be written to an output |
---|
1092 | file only |
---|
1093 | \item OASIS\_SentOut (=8) if the field would be both written to an |
---|
1094 | output file and sent to another component (directly or via OASIS3 |
---|
1095 | main process) |
---|
1096 | \item OASIS\_ToRestOut (=9) if the field would be written both to a |
---|
1097 | restart file and to an output file. |
---|
1098 | \item OASIS\_Ok (=0) otherwise and no error occurred. |
---|
1099 | \end{itemize} |
---|
1100 | \end{itemize} |
---|
1101 | |
---|
1102 | This routine may be called at any time to |
---|
1103 | inquire what would happen to the corresponding field (i.e. with same |
---|
1104 | {\tt var\_id} and at same {\tt date}) below the corresponding {\tt |
---|
1105 | oasis\_put}. This maybe useful if, for example, the calculation of |
---|
1106 | a coupling field is costly and if one wants to compute it only when it is |
---|
1107 | really sent out. |
---|
1108 | |
---|
1109 | \item {\tt CALL oasis\_get\_ncpl(var\_id, ncpl, kinfo)} |
---|
1110 | \item {\tt CALL prism\_get\_ncpl\_proto(var\_id, ncpl, kinfo)} |
---|
1111 | \begin{itemize} |
---|
1112 | \item {\tt var\_id [INTEGER; IN]}: field ID (from |
---|
1113 | corresponding oasis\_def\_var) |
---|
1114 | \item {\tt ncpl [INTEGER; OUT]}: number of coupling exchanges in which the field |
---|
1115 | is involved (i.e. when a field is sent to multiple targets) |
---|
1116 | \item {\tt kinfo [INTEGER; OUT]}: returned info code |
---|
1117 | \end{itemize} |
---|
1118 | |
---|
1119 | This routine returns the number of coupling exchanges in which the field var\_id is |
---|
1120 | involved. This number is needed to get the coupling frequencies with the |
---|
1121 | routine oasis\_get\_freqs, see below. |
---|
1122 | |
---|
1123 | \item {\tt CALL oasis\_get\_freqs(var\_id, mop, ncpl, cpl\_freqs, kinfo)} |
---|
1124 | \item {\tt CALL prism\_get\_freqs\_proto(var\_id, mop, ncpl, cpl\_freqs, kinfo)} |
---|
1125 | \begin{itemize} |
---|
1126 | \item {\tt var\_id [INTEGER; IN]}: field ID (from |
---|
1127 | corresponding oasis\_def\_var) |
---|
1128 | \item {\tt mop [INTEGER; IN]}: OASIS\_Out or OASIS\_In type |
---|
1129 | \item {\tt ncpl [INTEGER; IN]}: number of couplings in which the field |
---|
1130 | is involved (i.e. when a field is sent to multiple targets) |
---|
1131 | \item {\tt cpl\_freqs [INTEGER; DIMENSION(ncpl); OUT]}: coupling period(s) |
---|
1132 | (in number of seconds) of field var\_id. There is one coupling period for |
---|
1133 | each coupling exchange in which the field is involved |
---|
1134 | \item {\tt kinfo [INTEGER; OUT]}: returned info code |
---|
1135 | \end{itemize} |
---|
1136 | |
---|
1137 | This routine can be used to retrieve the coupling period(s) of field with |
---|
1138 | corresponding {\tt var\_id}, as defined in the {\it namcouple} |
---|
1139 | |
---|
1140 | \end{itemize} |
---|
1141 | |
---|
1142 | \section{OASIS3-MCT C API} |
---|
1143 | \label{APIC} |
---|
1144 | |
---|
1145 | OASIS3-MCT is distributed with C bindings and can be called from models written |
---|
1146 | in C and in C++. These bindings leverage the Fortran ISO\_C\_BINDING standard. |
---|
1147 | The C bindings can be compiled into static or shared libraries by the |
---|
1148 | OASIS3-MCT TopMakefileOasis3 as documented in \ref{subsec_compile}. |
---|
1149 | |
---|
1150 | The C interfaces largely match |
---|
1151 | up with equivalent interfaces in Fortran. An interface named |
---|
1152 | {\tt oasis\_interface} in Fortran can be expected to be named |
---|
1153 | {\tt oasis\_c\_interface} in C. |
---|
1154 | |
---|
1155 | All of the C interfaces return an integer error code which can be |
---|
1156 | tested against the {\tt OASIS\_Ok} (or the equivalent {\tt |
---|
1157 | OASIS\_Success}) constant. |
---|
1158 | The {\tt OASIS\_CHECK\_ERR} macro aborts |
---|
1159 | OASIS3-MCT with a meaningful message in the debug files in case of failure. |
---|
1160 | For most of the functions, |
---|
1161 | the return code is consistent with the {\tt |
---|
1162 | kinfo} argument in the Fortran interfaces. However, for the put and get communication functions, the return error code only indicates |
---|
1163 | success or failure, while the detailed status is returned by the {\tt |
---|
1164 | kinfo} argument (equivalent to the returned value of {\tt |
---|
1165 | info} argument for the Fortran {\tt oasis\_put} and {\tt oasis\_get} routines, see section \ref{prismput}). |
---|
1166 | |
---|
1167 | For example, the following constructs are equivalent in the two languages: |
---|
1168 | |
---|
1169 | \begin{verbatim} |
---|
1170 | call oasis_get_localcomm(localcomm, kinfo) |
---|
1171 | if (kinfo .ne. OASIS_Ok) & |
---|
1172 | & call OASIS_Abort(comp_id, "oasis_get_localcomm", & |
---|
1173 | & "Runtime error", __FILE__, __LINE__) |
---|
1174 | \end{verbatim} |
---|
1175 | |
---|
1176 | and |
---|
1177 | |
---|
1178 | \begin{verbatim} |
---|
1179 | OASIS_CHECK_ERR(oasis_get_localcomm(localcomm)) |
---|
1180 | \end{verbatim} |
---|
1181 | |
---|
1182 | For convenience a similar macro {\tt OASIS\_CHECK\_MPI\_ERR} has been |
---|
1183 | defined for testing the return code of any MPI function against {\tt |
---|
1184 | MPI\_SUCCESS} and cleanly aborting OASIS3-MCT in case of failure. |
---|
1185 | |
---|
1186 | \vspace{0.2cm} |
---|
1187 | More information about all these interfaces can be found in the |
---|
1188 | Fortran interface section (see \ref{API}). Use of these C bindings are illustrated in practical examples in |
---|
1189 | directories {\tt /C} in the different subdirectories in {\tt pyoasis/examples/}. Notes and deviations from |
---|
1190 | the Fortran standard are noted below. |
---|
1191 | |
---|
1192 | \vspace{0.2cm} |
---|
1193 | \begin{itemize} |
---|
1194 | |
---|
1195 | \item To use the OASIS3-MCT C bindings, the statement |
---|
1196 | \begin{verbatim} |
---|
1197 | #include "oasis_c.h" |
---|
1198 | \end{verbatim} |
---|
1199 | needs to be added to the C model source code. All available |
---|
1200 | parameters macros and |
---|
1201 | interfaces are defined there. |
---|
1202 | |
---|
1203 | \item {\tt int oasis\_c\_init\_comp(int* compid, const char* comp\_name, const bool coupled)} |
---|
1204 | \begin{itemize} |
---|
1205 | \item This {\tt oasis\_c\_init\_comp} interface includes the {\tt coupled} flag but |
---|
1206 | NO communicator argument ({\tt commworld}); to indicate a |
---|
1207 | communicator argument, see {\tt oasis\_c\_init\_comp\_with\_comm} below. |
---|
1208 | \item The {\tt coupled} argument can receive the predefined mnemonic boolean constants {\tt |
---|
1209 | OASIS\_Coupled} and {\tt OASIS\_Not\_Coupled} |
---|
1210 | \end{itemize} |
---|
1211 | |
---|
1212 | \vspace{0.2cm} |
---|
1213 | \item {\tt int oasis\_c\_init\_comp\_with\_comm(int* compid, const char* comp\_name, const bool coupled, const MPI\_Comm commworld)} |
---|
1214 | \begin{itemize} |
---|
1215 | \item This alternative {\tt init\_comp} interface has the {\tt coupled} flag and a C {\tt MPI\_Comm} communicator |
---|
1216 | \end{itemize} |
---|
1217 | |
---|
1218 | \vspace{0.2cm} |
---|
1219 | \item {\tt int oasis\_c\_get\_localcomm(MPI\_Comm* local\_comm)} |
---|
1220 | \begin{itemize} |
---|
1221 | \item Returns the local communicator by reference in a C {\tt MPI\_Comm*} type argument |
---|
1222 | \end{itemize} |
---|
1223 | |
---|
1224 | \vspace{0.2cm} |
---|
1225 | \item {\tt int oasis\_c\_create\_couplcomm(const int icpl, const MPI\_Comm local\_comm, MPI\_Comm* coupl\_comm)} |
---|
1226 | \begin{itemize} |
---|
1227 | \item {\tt loca\_comm} is a C {\tt MPI\_Comm} type input argument (by value) |
---|
1228 | |
---|
1229 | \item {\tt coupl\_comm} is a C {\tt MPI\_Comm*} type output argument (by reference) |
---|
1230 | \end{itemize} |
---|
1231 | |
---|
1232 | \vspace{0.2cm} |
---|
1233 | \item {\tt int oasis\_c\_set\_couplcomm(const MPI\_Comm coupl\_comm)} |
---|
1234 | \begin{itemize} |
---|
1235 | \item Takes a C {\tt MPI\_Comm} type as an input argument (by value) |
---|
1236 | \end{itemize} |
---|
1237 | |
---|
1238 | \vspace{0.2cm} |
---|
1239 | \item {\tt int oasis\_c\_def\_partition(int* il\_part\_id, const int ig\_paral\_size, const int* ig\_paral, const int ig\_size, const char* name)} |
---|
1240 | \begin{itemize} |
---|
1241 | \item {\tt ig\_paral\_size} is the size of the array {\tt ig\_paral}: the |
---|
1242 | {\tt oasis\_c.h} header provides a set of constants and macros for |
---|
1243 | the size of every partition strategy, namely {\tt |
---|
1244 | OASIS\_Serial\_Params}, {\tt OASIS\_Apple\_Params}, {\tt |
---|
1245 | OASIS\_Box\_Params}, {\tt |
---|
1246 | OASIS\_Orange\_Params(n\_segments)}, {\tt |
---|
1247 | OASIS\_Points\_Params(n\_points)} |
---|
1248 | \item the {\tt oasis\_c.h} header also provides a set of predefined |
---|
1249 | constants for the storages positions in {\tt |
---|
1250 | ig\_paral}, namely {\tt OASIS\_Strategy}, {\tt OASIS\_Segments}, {\tt |
---|
1251 | OASIS\_Npoints}, {\tt OASIS\_Offset}, {\tt OASIS\_Length}, {\tt |
---|
1252 | OASIS\_SizeX}, {\tt OASIS\_SizeY}, {\tt OASIS\_LdX} |
---|
1253 | \item the partition strategy, to be stored in the {\tt |
---|
1254 | OASIS\_Strategy} position of {\tt ig\_paral}, can take one of the |
---|
1255 | following predefined constants values: {\tt OASIS\_Serial}, {\tt |
---|
1256 | OASIS\_Apple}, {\tt OASIS\_Box}, {\tt OASIS\_Orange}, {\tt |
---|
1257 | OASIS\_Points} |
---|
1258 | \item for the cases in which the {\tt ig\_size} and {\tt name} |
---|
1259 | arguments are |
---|
1260 | not relevant for the partition definition, the placeholders {\tt |
---|
1261 | OASIS\_No\_Gsize} and {\tt OASIS\_No\_Name} can be used instead |
---|
1262 | \end{itemize} |
---|
1263 | Here an example for the {\tt OASIS\_Part\_Apple} strategy |
---|
1264 | \begin{verbatim} |
---|
1265 | int part_params[OASIS_Apple_Params]; |
---|
1266 | part_params[OASIS_Strategy] = OASIS_Apple; |
---|
1267 | part_params[OASIS_Offset] = offset; |
---|
1268 | part_params[OASIS_Length] = local_size; |
---|
1269 | int part_id; |
---|
1270 | OASIS_CHECK_ERR(oasis_c_def_partition(&part_id, OASIS_Apple_Params, |
---|
1271 | part_params, OASIS_No_Gsize, |
---|
1272 | OASIS_No_Name)); |
---|
1273 | \end{verbatim} |
---|
1274 | |
---|
1275 | \vspace{0.2cm} |
---|
1276 | \item {\tt int oasis\_c\_start\_grids\_writing()} |
---|
1277 | |
---|
1278 | \vspace{0.2cm} |
---|
1279 | \item {\tt int oasis\_c\_write\_grid(const char* cgrid, const int nx\_global, const int ny\_global, const int nx\_loc, const int ny\_loc, const double* lon, const double* lat, const int il\_partid)} |
---|
1280 | \begin{itemize} |
---|
1281 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1282 | of the global grid |
---|
1283 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1284 | of the local arrays {\tt lon} and {\tt lat} |
---|
1285 | \item {\tt lon} and {\tt lat} are stored with a fortran compatible |
---|
1286 | (column major) ordering. For example, if they are declared as double |
---|
1287 | pointers, they have to be {\tt lon[ny\_loc][nx\_loc]} |
---|
1288 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1289 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1290 | can be passed as a placeholder |
---|
1291 | \end{itemize} |
---|
1292 | |
---|
1293 | \vspace{0.2cm} |
---|
1294 | \item {\tt int oasis\_c\_write\_corner(const char* cgrid, const int nx\_global, const int ny\_global, const int nc, const int nx\_loc, const int ny\_loc, const double* clon, const double* clat, const int il\_partid)} |
---|
1295 | \begin{itemize} |
---|
1296 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1297 | of the global grid |
---|
1298 | \item {\tt nc} is the maximum number of corners per cell |
---|
1299 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1300 | of the local arrays {\tt clon} and {\tt clat} |
---|
1301 | \item {\tt clon} and {\tt clat} are stored with a fortran compatible |
---|
1302 | (column major) ordering. If they are declared as triple |
---|
1303 | pointers, they have to be {\tt clon[nc][ny\_loc][nx\_loc]} |
---|
1304 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1305 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1306 | can be passed as a placeholder |
---|
1307 | \end{itemize} |
---|
1308 | |
---|
1309 | \vspace{0.2cm} |
---|
1310 | \item {\tt int oasis\_c\_write\_mask(const char* cgrid, const int nx\_global, const int ny\_global, const int nx\_loc, const int ny\_loc, const int* mask, const int il\_partid, const char* companion)} |
---|
1311 | \begin{itemize} |
---|
1312 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1313 | of the global grid |
---|
1314 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1315 | of the local array {\tt mask} |
---|
1316 | \item {\tt mask} is stored with a fortran compatible |
---|
1317 | (column major) ordering. If it is declared as a double |
---|
1318 | pointer, it has to be {\tt mask[ny\_loc][nx\_loc]} |
---|
1319 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1320 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1321 | can be passed as a placeholder |
---|
1322 | \item if no {\tt companion} grid attribute is needed, the constant |
---|
1323 | {\tt OASIS\_No\_Companion} can be passed as a placeholder |
---|
1324 | \end{itemize} |
---|
1325 | |
---|
1326 | \vspace{0.2cm} |
---|
1327 | \item {\tt int oasis\_c\_write\_frac(const char* cgrid, const int nx\_global, const int ny\_global, const int nx\_loc, const int ny\_loc, const double* frac, const int il\_partid, const char* companion)} |
---|
1328 | \begin{itemize} |
---|
1329 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1330 | of the global grid |
---|
1331 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1332 | of the local array {\tt frac} |
---|
1333 | \item {\tt frac} is stored with a fortran compatible |
---|
1334 | (column major) ordering. If it is declared as a double |
---|
1335 | pointer, it has to be {\tt frac[ny\_loc][nx\_loc]} |
---|
1336 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1337 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1338 | can be passed as a placeholder |
---|
1339 | \item if no {\tt companion} grid attribute is needed, the constant |
---|
1340 | {\tt OASIS\_No\_Companion} can be passed as a placeholder |
---|
1341 | \end{itemize} |
---|
1342 | |
---|
1343 | \vspace{0.2cm} |
---|
1344 | \item {\tt int oasis\_c\_write\_area(const char* cgrid, const int nx\_global, const int ny\_global, const int nx\_loc, const int ny\_loc, const double* area, const int il\_partid)} |
---|
1345 | \begin{itemize} |
---|
1346 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1347 | of the global grid |
---|
1348 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1349 | of the local array {\tt area} |
---|
1350 | \item {\tt area} is stored with a fortran compatible |
---|
1351 | (column major) ordering. If it is declared as a double |
---|
1352 | pointer, it has to be {\tt area[ny\_loc][nx\_loc]} |
---|
1353 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1354 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1355 | can be passed as a placeholder |
---|
1356 | \end{itemize} |
---|
1357 | |
---|
1358 | \vspace{0.2cm} |
---|
1359 | \item {\tt int oasis\_c\_write\_angle(const char* cgrid, const int nx\_global, const int ny\_global, const int nx\_loc, const int ny\_loc, const double* angle, const int il\_partid)} |
---|
1360 | \begin{itemize} |
---|
1361 | \item {\tt nx\_global} and {\tt ny\_global} are the first and second dimensions |
---|
1362 | of the global grid |
---|
1363 | \item {\tt nx\_loc} and {\tt ny\_loc} are the two dimensions |
---|
1364 | of the local array {\tt angle} |
---|
1365 | \item {\tt angle} is stored with a fortran compatible |
---|
1366 | (column major) ordering. If it is declared as a double |
---|
1367 | pointer, it has to be {\tt angle[ny\_loc][nx\_loc]} |
---|
1368 | \item {\tt il\_partid} is relevant only for parallel writing. In case |
---|
1369 | of single proc invocations, the constant {\tt OASIS\_No\_Part} |
---|
1370 | can be passed as a placeholder |
---|
1371 | \end{itemize} |
---|
1372 | |
---|
1373 | \vspace{0.2cm} |
---|
1374 | \item {\tt int oasis\_c\_terminate\_grids\_writing()} |
---|
1375 | |
---|
1376 | \vspace{0.2cm} |
---|
1377 | \item {\tt int oasis\_c\_def\_var(int* var\_id, const char* name, const int il\_part\_id, const bundle\_size, const int kinout, const int var\_type)} |
---|
1378 | \begin{itemize} |
---|
1379 | \item {\tt bundle\_size} is a scalar integer, corresponding to the |
---|
1380 | second entry of the fortran {\tt var\_nodims} array |
---|
1381 | \item {\tt kinout} can receive one of the two predefined constants |
---|
1382 | {\tt OASIS\_In} or {\tt OASIS\_Out} (also in the form |
---|
1383 | {\tt OASIS\_IN} or {\tt OASIS\_OUT}) |
---|
1384 | \item {\tt var\_type} can receive one of the two predefined constants |
---|
1385 | {\tt OASIS\_Real} or {\tt OASIS\_Double} (also in the form |
---|
1386 | {\tt OASIS\_REAL} or {\tt OASIS\_DOUBLE}) |
---|
1387 | \end{itemize} |
---|
1388 | |
---|
1389 | \vspace{0.2cm} |
---|
1390 | \item {\tt int oasis\_c\_enddef()} |
---|
1391 | |
---|
1392 | \vspace{0.2cm} |
---|
1393 | \item {\tt int oasis\_c\_put(const int var\_id, const int date, const |
---|
1394 | int x\_size, const int y\_size, const int bundle\_size, const int |
---|
1395 | fkind, const int storage, const void* fld1, const bool |
---|
1396 | write\_restart, int* kinfo)} |
---|
1397 | \begin{itemize} |
---|
1398 | \item This interface does not support higher order mapping through optional fields at this time. |
---|
1399 | \item {\tt x\_size}, {\tt y\_size}, are the dimensions of the local |
---|
1400 | portion of the domain, i.e. fld1. The order of these dimensions must be the same than the order of the dimensions of the arrays in the {\tt |
---|
1401 | grids.nc} file, which corresponds to the storage order in the |
---|
1402 | corresponding internal OASIS3-MCT Fortran work arrays. \\ |
---|
1403 | Notice that for |
---|
1404 | unstructured grids {\tt y\_size=1} |
---|
1405 | \item {\tt bundle\_size} should be coherent with the argument of |
---|
1406 | same name in the corresponding {\tt oasis\_c\_def\_var} |
---|
1407 | \item {\tt fkind} can take one of the two predefined constants |
---|
1408 | {\tt OASIS\_Real} or {\tt OASIS\_Double} (also in the form |
---|
1409 | {\tt OASIS\_REAL} or {\tt OASIS\_DOUBLE}) should be coherent with |
---|
1410 | the argument {\tt ktype} in {\tt oasis\_c\_def\_var} |
---|
1411 | \item {\tt storage} can take one of the two predefined constants |
---|
1412 | {\tt OASIS\_COL\_MAJOR} or \\ |
---|
1413 | {\tt OASIS\_ROW\_MAJOR}. \\ |
---|
1414 | In the first |
---|
1415 | case, the array containing the field has to be declared as \\ {\tt |
---|
1416 | field[bundle\_size][y\_size][x\_size]} (or any equivalent |
---|
1417 | storage of total size \\ |
---|
1418 | {\tt bundle\_size*y\_size*x\_size} stored in |
---|
1419 | column major order. \\ |
---|
1420 | In the second case, the field has to be |
---|
1421 | declared as \\ |
---|
1422 | {\tt field[x\_size][y\_size][bundle\_size]} (or any |
---|
1423 | equivalent row major storage). \\ |
---|
1424 | Notice that this choice implies an |
---|
1425 | extra memory copy performed internally by OASIS3-MCT before acting on |
---|
1426 | the field and is therefore to be avoided whenever possible. |
---|
1427 | \item {\tt write\_restart} can take one of the two predefined constants |
---|
1428 | {\tt OASIS\_Write\_Restart} or {\tt OASIS\_No\_Restart} |
---|
1429 | \item {\tt kinfo} contains a return status to be compared against |
---|
1430 | the values of the {\tt return\_codes} enumeration in {\tt oasis\_c.h} (equivalent to the returned value of {\tt |
---|
1431 | info} argument for the Fortran {\tt oasis\_put} routine, see section \ref{prismput}) |
---|
1432 | \end{itemize} |
---|
1433 | |
---|
1434 | \vspace{0.2cm} |
---|
1435 | \item {\tt int oasis\_c\_get(const int var\_id, const int date, const |
---|
1436 | int x\_size, const int y\_size, const int bundle\_size, const int |
---|
1437 | fkind, const int storage, void* fld1, int* kinfo)} |
---|
1438 | \begin{itemize} |
---|
1439 | \item arguments are the same than for {\tt oasis\_c\_put}, except that {\tt kinfo} return |
---|
1440 | status is equivalent to the returned value of {\tt |
---|
1441 | info} argument for the Fortran {\tt oasis\_get} routine, see section \ref{prismput}. |
---|
1442 | \end{itemize} |
---|
1443 | |
---|
1444 | \vspace{0.2cm} |
---|
1445 | \item {\tt int oasis\_c\_terminate()} |
---|
1446 | |
---|
1447 | \vspace{0.2cm} |
---|
1448 | \item {\tt int oasis\_c\_abort(const int compid, const char* routine\_name, const char* abort\_message, const char* file, const int line)} |
---|
1449 | |
---|
1450 | \vspace{0.2cm} |
---|
1451 | \item {\tt int oasis\_c\_get\_debug(int* debug)} |
---|
1452 | |
---|
1453 | \vspace{0.2cm} |
---|
1454 | \item {\tt int oasis\_c\_set\_debug(const int debug)} |
---|
1455 | |
---|
1456 | \vspace{0.2cm} |
---|
1457 | \item {\tt int oasis\_c\_get\_intercomm(MPI\_Comm* new\_comm, char* cdnam)} |
---|
1458 | \begin{itemize} |
---|
1459 | \item Returns a C MPI\_Comm type by reference |
---|
1460 | \end{itemize} |
---|
1461 | |
---|
1462 | \vspace{0.2cm} |
---|
1463 | \item {\tt int oasis\_c\_get\_intracomm(MPI\_Comm* new\_comm, char* cdnam)} |
---|
1464 | \begin{itemize} |
---|
1465 | \item Returns a C MPI\_Comm type as by reference |
---|
1466 | \end{itemize} |
---|
1467 | |
---|
1468 | \vspace{0.2cm} |
---|
1469 | \item {\tt int oasis\_c\_get\_multi\_intracomm(MPI\_Comm* new\_comm, const int cdnam\_size, char** cdnam, int* root\_ranks)} |
---|
1470 | \begin{itemize} |
---|
1471 | \item Returns a C MPI\_Comm type as by reference |
---|
1472 | \item cdnam\_size is the size of the array cdnam |
---|
1473 | \end{itemize} |
---|
1474 | |
---|
1475 | \vspace{0.2cm} |
---|
1476 | \item {\tt int oasis\_c\_put\_inquire(int var\_id, int date, int* kinfo)} |
---|
1477 | \begin{itemize} |
---|
1478 | \item {\tt kinfo} contains a return status to be compared against |
---|
1479 | the values of the {\tt return\_codes} enumeration in {\tt oasis\_c.h} |
---|
1480 | \end{itemize} |
---|
1481 | |
---|
1482 | \vspace{0.2cm} |
---|
1483 | \item {\tt int oasis\_c\_get\_ncpl(const int var\_id, int* ncpl)} |
---|
1484 | |
---|
1485 | \vspace{0.2cm} |
---|
1486 | \item {\tt int oasis\_c\_get\_freqs(const int var\_id, const int mop, const int ncpl, int* cpl\_freqs)} |
---|
1487 | |
---|
1488 | \end{itemize} |
---|
1489 | |
---|
1490 | \section{OASIS3-MCT python API} |
---|
1491 | \label{APIpython} |
---|
1492 | |
---|
1493 | The source code of pyOASIS is in the directory {\tt pyoasis/src}. A complete documentation is available in {\tt pyoasis/pyoasis.pdf} and examples on how to use pyOASIS are provided in {\tt pyoasis/examples}. |
---|
1494 | |
---|
1495 | First, the OASIS3-MCT Fortran code is wrapped in Fortran using ISO-C bindings. The corresponding source files are in the subdirectory {\tt lib/cbindings/fortran\_isoc}. The file names are the same as the corresponding ones in the original source code but ending in {\tt \_iso.F90}. Subsequently, the Fortran with ISO-C bindings is wrapped in C, see the source code in {\tt lib/cbindings/c\_src}. The names of the files are the same as the corresponding Fortran ones, but ending in {\tt \_c.c}. Finally, the C is wrapped in Python in the directory {\tt pyoasis/src}; a low-level wrapper is made using the same file names as the Fortran ones but ending with {\tt .py}. |
---|
1496 | The python wrapper functions are briefly described hereafer. |
---|
1497 | To run all tests including python, C and fortran examples from {\tt pyoasis/examples}, use {\tt make test}. |
---|
1498 | |
---|
1499 | \begin{itemize} |
---|
1500 | \item{Creating a component using MPI} |
---|
1501 | \label{index:creating-a-component-using-mpi} |
---|
1502 | |
---|
1503 | In pyOASIS, components are instances of the {\tt Component} class. To |
---|
1504 | initialise a component, its name has to be supplied. |
---|
1505 | It is also possible to provide an optional {\tt coupling\_flag} argument which |
---|
1506 | defaults to âTrueâ, which means the component is coupled through OASIS3\_MCT. |
---|
1507 | |
---|
1508 | OASIS3\_MCT couples models which communicate using MPI. |
---|
1509 | If the global communicator gathering at start all components of the coupled model is different from the default {\tt MPI\_COMM\_WORLD}, the global communicator has to be passed to the {\tt Component} class through the third |
---|
1510 | optional argument. By default, the |
---|
1511 | {\tt Component} class will set up MPI internally and provides methods |
---|
1512 | to get access to information such as rank and number of processes in |
---|
1513 | the local communicator gathering only the component processes. |
---|
1514 | |
---|
1515 | \begin{verbatim} |
---|
1516 | ____________________________________________________________ |
---|
1517 | import pyoasis |
---|
1518 | [...] |
---|
1519 | comm = my_global_comm |
---|
1520 | component_name = "component" |
---|
1521 | coupling_flag = True |
---|
1522 | comp = pyoasis.Component(component_name, coupling_flag, comm) |
---|
1523 | print("Hello world from process " + str(comp.localcomm.rank) |
---|
1524 | + " of " + str(comp.localcomm.size)) |
---|
1525 | ____________________________________________________________ |
---|
1526 | \end{verbatim} |
---|
1527 | |
---|
1528 | To create a coupling communicator for a subset of processes, one can |
---|
1529 | use the method {\tt create\_couplcomm}, with a flag being {\tt True} for all these |
---|
1530 | processes; see {\tt pyoasis/examples/4-orange/python} for a practical example. |
---|
1531 | |
---|
1532 | If such a communicator already exists in the code, it should simply |
---|
1533 | provided to OASIS3\_MCT with the method {\tt set\_couplcomm}; |
---|
1534 | as in {\tt pyoasis/examples/6-apple\_and\_orange/python}. |
---|
1535 | |
---|
1536 | To set up an MPI intra communicator or inter communicator between the local component and |
---|
1537 | another component, one can use the methods {\tt get\_intracomm} or {\tt get\_intercomm}; |
---|
1538 | \newline |
---|
1539 | as in {\tt pyoasis/examples/3-box/python} . |
---|
1540 | |
---|
1541 | To set up an MPI intra-communicator among some of the coupled components, listed in the {\tt comp\_list} list, |
---|
1542 | one can use the method {\tt get\_multi\_intracomm}, as in {\tt 9-python\_fortran\_C-multi\_intracomm}. |
---|
1543 | |
---|
1544 | Also, the current OASIS3-MCT internal debug level ({\tt \$NLOGPRT} |
---|
1545 | value in the {\it namcouple}), can be retrieved as a property of a component, |
---|
1546 | namely {\tt debug\_level}, and can be changed by directly modifying this property, |
---|
1547 | as in {\tt pyoasis/examples/7-multiple-puts/python}. |
---|
1548 | |
---|
1549 | \item{Creating a partition} |
---|
1550 | \label{{index:creating-a-partition}} |
---|
1551 | |
---|
1552 | The data can be partitioned in various ways. |
---|
1553 | These correspond to the {\tt SerialPartition}, {\tt ApplePartition}, |
---|
1554 | {\tt BoxPartition}, {\tt OrangePartition} and {\tt PointsPartition} |
---|
1555 | classes which are inherited from the {\tt Partition} abstract class. |
---|
1556 | For details on the different ways to describe the partitions, |
---|
1557 | see OASIS3\_MCT User Guide, section 2.2.3 and examples {\tt 1\_serial}, |
---|
1558 | {\tt 2\_apple}, {\tt 3\_box}, {\tt 4\_orange}, {\tt 5\_points} in {\tt pyoasis/examples}. |
---|
1559 | |
---|
1560 | The simplest situation is the serial partitioning where all the data is |
---|
1561 | held by a single process and only the number of points has to be |
---|
1562 | specified (see example {\tt 1\_serial}) |
---|
1563 | |
---|
1564 | In the case of the Apple partitioning, each process contains a segment |
---|
1565 | of a linear domain. To initialise such a partitioning, an offset has to |
---|
1566 | be supplied for each rank as well as the number of data points that |
---|
1567 | will be stored locally (see example {\tt 2\_apple}). |
---|
1568 | |
---|
1569 | When we use the Box partitioning, a two-dimensional domain is split |
---|
1570 | into several rectangles. The global offset, local extents in the x and |
---|
1571 | y directions and the global extent in the x direction have to be supplied |
---|
1572 | to the constructor. The global offset is the index of the corner of the local |
---|
1573 | rectangle (see example in {\tt 3\_box}) . |
---|
1574 | |
---|
1575 | The Orange partitioning consists of several segments of a linear domain (see an example with only one segment per process in {\tt 4\_orange}.) |
---|
1576 | |
---|
1577 | The last type of partitioning is Points, where we have to |
---|
1578 | specify, in a list, the global indices of the points stored by the |
---|
1579 | process (see example in {\tt 5\_points}). |
---|
1580 | |
---|
1581 | \item{Defining the coupling grids} |
---|
1582 | \label{index:defining-the-coupling-grids} |
---|
1583 | |
---|
1584 | The grid data files, containing the definition of the grids onto which |
---|
1585 | the coupling data is defined, can be created by the user before the |
---|
1586 | run or can be written directly at run time by the components, either |
---|
1587 | by one component process to write the whole grid or by each process |
---|
1588 | holding a part of a grid. Details |
---|
1589 | about the grid definition can be found in section 2.2.4 of OASIS3\_MCT |
---|
1590 | User Guide. A full example of writing a grid in sequential and |
---|
1591 | parallel models can be found in {\tt examples/10\_grid} . |
---|
1592 | |
---|
1593 | To initialise a grid and write the grid longitudes and latitudes, one |
---|
1594 | has to create an instance of the {\tt Grid} class. Then to write the grid cell corner longitudes and latitudes, areas, mask, cell valid fraction, angle, the |
---|
1595 | {\tt set\_corners}, {\tt set\_area}, {\tt set\_mask}, {\tt set\_frac}, and {\tt set\_angle} methods can be used respectively. |
---|
1596 | |
---|
1597 | \item{Declaring the coupling data} |
---|
1598 | \label{{index:declaring-the-coupling-data}} |
---|
1599 | |
---|
1600 | The coupling data is handled by the class {\tt Var}. Its constructor requires |
---|
1601 | its symbolic name, as it appears in the {\it namcouple} file, the partition and a flag indicating whether the |
---|
1602 | data is incoming or outgoing. The latter is an enumerated type and can |
---|
1603 | have the values {\tt pyoasis.OasisParameters.OASIS\_OUT} or |
---|
1604 | {\tt pyoasis.OasisParameters.OASIS\_IN}. |
---|
1605 | |
---|
1606 | The property {\tt is\_active} can be tested to check if the variable is |
---|
1607 | activated in the {\it namcouple} configuring file (see {\tt example 3-box/python}). |
---|
1608 | |
---|
1609 | The coupling period(s) of the data, as defined in the {\it namcouple}, can be |
---|
1610 | accessed with the property {\tt cpl\_freqs} and the number of coupling exchanges in |
---|
1611 | which the data is involved by {\tt len(cpl\_freqs)} (see example {\tt 7-multiple-puts/python}). |
---|
1612 | |
---|
1613 | The property {\tt put\_inquire} of the variable tells what would happen to the corresponding data at that date |
---|
1614 | below the corresponding send action. This maybe useful if, for |
---|
1615 | example, the calculation of a coupling field is costly and if one |
---|
1616 | wants to compute it only when it is really sent out. The |
---|
1617 | different possible return codes are listed in section 2.2.9 of |
---|
1618 | OASIS3\_MCT User Guide. |
---|
1619 | |
---|
1620 | \item{Ending the definition phase} |
---|
1621 | \label{{index:ending-the-definition-phase}} |
---|
1622 | |
---|
1623 | Then the definition of the component must be ended by calling the {\tt enddef()} |
---|
1624 | method. This must be done only once the partitioning and the variable data have been initalised. |
---|
1625 | |
---|
1626 | \item{Sending and receiving data} |
---|
1627 | \label{{index:sending-and-receiving-data}} |
---|
1628 | |
---|
1629 | pyOASIS expects data to be provided as a {\tt pyoasis.asarray} object: |
---|
1630 | |
---|
1631 | \begin{verbatim} |
---|
1632 | ____________________________________________________________ |
---|
1633 | field = pyoasis.asarray(range(n_points)) |
---|
1634 | ____________________________________________________________ |
---|
1635 | \end{verbatim} |
---|
1636 | |
---|
1637 | This is a Numpy array but ordered in the Fortran way. |
---|
1638 | In C, multidimensional arrays store data in row\_major order where |
---|
1639 | contiguous elements are accessed by incrementing the rightmost index |
---|
1640 | while varying the other indices will correspond to increasing strides in |
---|
1641 | memory as we use indices further towards the left. By default, Numpy arrays |
---|
1642 | use that ordering as well. Fortran, on the other hand, uses column\_major |
---|
1643 | order. In that case, contiguous elements are accessed by incrementing |
---|
1644 | the leftmost index. {\tt pyoasis.asarray} objects use the same ordering as |
---|
1645 | Fortran. As a consequence, it is not necessary to transform data in order to |
---|
1646 | use it in the OASIS3\_MCT Fortran library. |
---|
1647 | |
---|
1648 | The sending and receiving actions may be called by the component at |
---|
1649 | each timestep. The date argument is automatically analysed and actions |
---|
1650 | are actually performed only if date corresponds to a time for which it |
---|
1651 | should be activated, given the period indicated by the user in the |
---|
1652 | namcouple. See OASIS3\_MCT User Guide section 2.2.7 for details. |
---|
1653 | |
---|
1654 | The data is sent with the {\tt put} function. |
---|
1655 | |
---|
1656 | \begin{verbatim} |
---|
1657 | ____________________________________________________________ |
---|
1658 | date = int(0) |
---|
1659 | variable.put(date, field) |
---|
1660 | ____________________________________________________________ |
---|
1661 | \end{verbatim} |
---|
1662 | |
---|
1663 | Conversely, it is received with the {\tt get} function, which fills the {\tt pyoasis.asarray} object. |
---|
1664 | |
---|
1665 | \begin{verbatim} |
---|
1666 | ____________________________________________________________ |
---|
1667 | variable.get(date, field) |
---|
1668 | ____________________________________________________________ |
---|
1669 | \end{verbatim} |
---|
1670 | |
---|
1671 | \item{Termination} |
---|
1672 | \label{{index:termination}} |
---|
1673 | |
---|
1674 | Finally, the coupling is terminated with the destruction of |
---|
1675 | the component: |
---|
1676 | |
---|
1677 | \begin{verbatim} |
---|
1678 | ____________________________________________________________ |
---|
1679 | del comp |
---|
1680 | ____________________________________________________________ |
---|
1681 | \end{verbatim} |
---|
1682 | |
---|
1683 | |
---|
1684 | \item{Exceptions and aborting} |
---|
1685 | \label{{index:exceptions-and-aborting}} |
---|
1686 | |
---|
1687 | When an error occurs in OASIS3\_MCT, the code coupler returns an error |
---|
1688 | code and an {\tt OasisException} is raised. In practice, OASIS3\_MCT will |
---|
1689 | internally handle the error, write an error message in its |
---|
1690 | debug log files and to the screen, and abort before the exception is raised. It |
---|
1691 | may also happen that the code aborts before the error message appears |
---|
1692 | on the screen. |
---|
1693 | |
---|
1694 | When an error is caught by the pyOASIS wrapper, such as an incorrect parameter |
---|
1695 | or a wrong argument type, a {\tt PyOasisException} is raised. |
---|
1696 | |
---|
1697 | In the following example, where we attempt to initialise a component, |
---|
1698 | a {\tt PyOasisException} will be raised as the user supplies an empty |
---|
1699 | name : |
---|
1700 | |
---|
1701 | \begin{verbatim} |
---|
1702 | ____________________________________________________________ |
---|
1703 | try: |
---|
1704 | comp = pyoasis.Component("") |
---|
1705 | except (pyoasis.PyOasisException) as exception: |
---|
1706 | pyoasis.pyoasis_abort(exception) |
---|
1707 | ____________________________________________________________ |
---|
1708 | \end{verbatim} |
---|
1709 | |
---|
1710 | The function {\tt pyoasis.pyoasis\_abort} takes an exception as argument. |
---|
1711 | It stops the execution of all the processes after having displayed an error message and |
---|
1712 | written information in the log files about the error and the context in |
---|
1713 | which it took place. |
---|
1714 | |
---|
1715 | Another function is available, {\tt pyoasis.oasis\_abort}, |
---|
1716 | for the cases where a voluntary abort is needed in the code where or |
---|
1717 | not an exception has been raised. Its interface mimics the |
---|
1718 | corresponding OASIS3\_MCT functio {\tt oasis\_abort}. |
---|
1719 | |
---|
1720 | \end{itemize} |
---|
1721 | |
---|
1722 | \subsection{Fortran python API correspondence} |
---|
1723 | |
---|
1724 | Figures \ref{python_corresp_init} , \ref{python_corresp_grid} and \ref{python_corresp_terminate} show the Fortran python API correspondence for different parts of the API. Different examples implementing the different parts of the API with the Fortran, C and python interfaces are also provided as practical illustrations in directory {\tt pyoasis/examples} and are described in section \ref{subsec_equivalent}. |
---|
1725 | |
---|
1726 | \begin{figure}[h] |
---|
1727 | \includegraphics[scale=.45]{figures/corresp_init.pdf} |
---|
1728 | \caption{Fortran python AP correspondence for the initialisation, communication and partition definition.} |
---|
1729 | \label{python_corresp_init} |
---|
1730 | \end{figure} |
---|
1731 | |
---|
1732 | \begin{figure}[h] |
---|
1733 | \includegraphics[scale=.45]{figures/corresp_grid.pdf} |
---|
1734 | \caption{Fortran python AP correspondence for the grid definition, variable declaration and end of definition phase.} |
---|
1735 | \label{python_corresp_grid} |
---|
1736 | \end{figure} |
---|
1737 | |
---|
1738 | \begin{figure}[h] |
---|
1739 | \includegraphics[scale=.45]{figures/corresp_terminate.pdf} |
---|
1740 | \caption{Fortran python AP correspondence for the coupling field exchanges, termination and auxialiary routines.} |
---|
1741 | \label{python_corresp_terminate} |
---|
1742 | \end{figure} |
---|
1743 | |
---|
1744 | \newpage |
---|
1745 | |
---|
1746 | \section{Additonal notes on coupling functionality} |
---|
1747 | \label{sec_notes} |
---|
1748 | |
---|
1749 | \subsection{A brief overview of MCT} |
---|
1750 | \label{subsec_MCT} |
---|
1751 | |
---|
1752 | As described elsewhere, OASIS3-MCT leverages the MCT coupling infrastructure |
---|
1753 | developed at Argonne National Laboratory. That infrastructure is designed |
---|
1754 | to couple fields on static grids between model components. The fields |
---|
1755 | can be decomposed using MPI across mutiple processes, and the decomposition |
---|
1756 | and number of proceses involved can be arbitrary in each component. MCT |
---|
1757 | supports both communication of data between unique MPI non-overlapping |
---|
1758 | communicators and |
---|
1759 | within a single MPI communicator, although these two operations are functionally |
---|
1760 | independent within MCT. |
---|
1761 | |
---|
1762 | MCT also provides the ability to map (aka interpolate or |
---|
1763 | regrid) data between grids as long as the interpolation is linear and can |
---|
1764 | be computed by a linear sparse matrix multiply. |
---|
1765 | MCT does not compute inteporlation weights, but |
---|
1766 | it has interfaces that allow those weights to be passed into MCT. Within |
---|
1767 | MCT, mapping and communication are also treated as independent features. |
---|
1768 | |
---|
1769 | OASIS3-MCT supports both mapping and communication of data through MCT. As |
---|
1770 | a results, mapping and coupling are implemented, in many ways, as separate |
---|
1771 | steps in the underlying implementation. A coupling field that also requires |
---|
1772 | mapping will carry out the mapping on either the source or destination component |
---|
1773 | on the associated processes, while coupling between components will be done |
---|
1774 | either before or after mapping. In other words, a coupling field can be |
---|
1775 | interpolated to |
---|
1776 | the destination grid on the source processes then communicated to the destination |
---|
1777 | component OR a coupling field can be communicated to the destination component |
---|
1778 | on the source grid then mapped to the destination grid on the destination |
---|
1779 | component. At the present time, it is not possible to map the field as part |
---|
1780 | of the communication rearrangement, although in theory, that capability should |
---|
1781 | be possible to implement in the future, and OASIS3-MCT developers are considering |
---|
1782 | it. The separation of mapping and communication is handled by the OASIS |
---|
1783 | layer. Users only need to be aware of a few options that can be set to fine |
---|
1784 | tune the performance of these operations. |
---|
1785 | |
---|
1786 | OASIS3-MCT also imposes a few other constraints on the usage. MCT |
---|
1787 | does NOT support haloed communication. There must be a 1-to-1 relationship |
---|
1788 | between grid point values on the source grid and on the destination grid. |
---|
1789 | A user cannot send a single grid point value to multiple destination gridcells |
---|
1790 | or processes via OASIS3-MCT. The partitions defined by the user that define |
---|
1791 | the field decomposition cannot reference the same global gridcell more than once. |
---|
1792 | |
---|
1793 | OASIS3-MCT does not support dynamically varying grids nor dynamically varying |
---|
1794 | decompositions at the present time. MCT is NOT currently setup to support those |
---|
1795 | features. In the future, it is possible that some dynamic grid capabilities |
---|
1796 | might be supported through OASIS3-MCT but requirements and implementation are |
---|
1797 | still being assessed. |
---|
1798 | |
---|
1799 | Since the OASIS3-MCT\_4.0 release, OASIS3-MCT includes a mixed MPI+OpenMP parallel version of the SCRIP library for the calculation of the remapping weights (see section \ref{subsec_interp}). But besides this aspect, MCT itself, and therefore the communication layer in OASIS, has only minimal OpenMP support at the |
---|
1800 | present time. Users are discouraged from calling OASIS3-MCT {\tt oasis\_put} and {\tt oasis\_get} |
---|
1801 | from a threaded region. And it is not possible to define a partition (decomposition) |
---|
1802 | across multiple active threads. Most of the work that OASIS3-MCT does related to decomposition rearrangement for communication or mapping per se is MPI-based. There |
---|
1803 | are some floating point operations in the sparse matrix multiple as well as in |
---|
1804 | some of the OASIS transforms; but generally, these are highly parallel and |
---|
1805 | would often not benefit from use of OpenMP. OASIS3-MCT is designed primarily to |
---|
1806 | support large memory parallel applications that require efficient and scalable |
---|
1807 | coupling and mapping capabilities. |
---|
1808 | |
---|
1809 | MCT only supports coupling of integer or floating point data. Fields based on |
---|
1810 | logicals and character strings cannot be coupled. |
---|
1811 | |
---|
1812 | \subsection{Coupling scalar values} |
---|
1813 | \label{subsec_scalar} |
---|
1814 | |
---|
1815 | OASIS3-MCT does not have a distinct feature to support scalar coupling. By |
---|
1816 | scalar coupling, we mean scalar variables such as date and time, |
---|
1817 | logical flags, integer or real parameters, or other scalar data that might be |
---|
1818 | defined identically across all MPI tasks in a component or even just on the |
---|
1819 | root task or a subset of tasks. |
---|
1820 | It is often desirable to communicate scalar data between components |
---|
1821 | to coordinate scientific or technical features. There isn't a feature that |
---|
1822 | supports this type of coupling specifically, but it is possible to do so using |
---|
1823 | available interfaces. The most robust implementation is probably to setup |
---|
1824 | root to root coupling of scalars between components. To do so : |
---|
1825 | |
---|
1826 | \begin{itemize} |
---|
1827 | \item Determine the number and type of scalars to couple |
---|
1828 | \item Allocate an array in each component of that size |
---|
1829 | \item Initialize a partition using the POINTS approach (see section \ref{subsubsec_pointspart}) with the size of the array assigned to the root process in each component and no portion of the partition allocated to other processes. |
---|
1830 | \item Define coupling field names for use in both the model components and the namcouple file and declare variables as usual. Create a set of namcouple inputs. You will not need any mapping. |
---|
1831 | \item Use the {\tt oasis\_get} and {\tt oasis\_put} interfaces to communicate data between components. |
---|
1832 | \item If required, broadcast the scalars after being received from the root process to the other processes, outside the OASIS3-MCT layer. |
---|
1833 | \end{itemize} |
---|
1834 | |
---|
1835 | This can be extended as needed to send or receive from non root processes. But |
---|
1836 | you cannot send the scalar data to multiple processes as this violates the halo |
---|
1837 | restriction in MCT. Users need to be aware which processes contain valid scalar |
---|
1838 | data both on the source and destination side and to manage data synchronization |
---|
1839 | between processes within a component outside the OASIS3-MCT layer. |
---|
1840 | |
---|
1841 | \vspace{-0.3cm} |
---|
1842 | \subsection{The lag concept} |
---|
1843 | \label{subsec_lag} |
---|
1844 | |
---|
1845 | Using the OASIS3-MCT coupling library, the user has the flexibility |
---|
1846 | to reproduce different coupling algorithms defining {\tt LAG} values for the different coupling fields . |
---|
1847 | In the components, the |
---|
1848 | sending and receiving routines, respectively {\tt oasis\_put} and {\tt |
---|
1849 | oasis\_get}, can be called at each component timestep, with the |
---|
1850 | appropriate {\tt date} argument giving the actual time (at the |
---|
1851 | beginning of the timestep), expressed in number of seconds since the |
---|
1852 | start of the run, or in any other time units as long as the same are |
---|
1853 | used in all components and in the {\it namcouple} (see section |
---|
1854 | \ref{prismput}). This {\tt date} argument is automatically analysed by |
---|
1855 | the coupling library and depending on the coupling period and the lag chosen by the user for the coupling field in the {\it namcouple} ({\tt LAG}), different coupling algorithms can be reproduced |
---|
1856 | without modifying the component codes themselves. |
---|
1857 | |
---|
1858 | The lag ({\tt LAG}) must be |
---|
1859 | expressed in the time unit used (that must be the same in the components |
---|
1860 | and in the {\it namcouple}, see section \ref{prismput}) and can be |
---|
1861 | positive or negative but should never be larger (in absolute |
---|
1862 | magnitude) than the coupling period of any field due to problems with |
---|
1863 | restartability and dead-locking. When a component calls a {\tt |
---|
1864 | oasis\_put}, the value of the lag is automatically added to the |
---|
1865 | value of the {\tt date} argument and the ``put'' is actually performed |
---|
1866 | when the sum {\tt date+lag} is a coupling time; in the target |
---|
1867 | component, this ``put'' will match a {\tt oasis\_get} for which the |
---|
1868 | {\tt date} argument is the same coupling time. |
---|
1869 | % A positive lag indicates the put will occur sooner than zero lag and |
---|
1870 | % a negative lag tells the coupler to send the data later than zero |
---|
1871 | % lag. |
---|
1872 | So the lag only shifts the time at which the data is sent but not |
---|
1873 | the time at which the data is received. |
---|
1874 | |
---|
1875 | When the lag is positive, a restart file must be available to initiate |
---|
1876 | the coupling. For a field with positive lag, the source |
---|
1877 | component automatically reads the field in the restart file |
---|
1878 | during the coupling initialization phase (below the {\tt |
---|
1879 | oasis\_enddef}) and send the data to match the {\tt oasis\_get} |
---|
1880 | performed at time=0 in the target component. The final coupling |
---|
1881 | data on the source side will then be automatically written to the |
---|
1882 | restart file for use in the next run\footnote{When there is a lag, the first and last instance of the source field |
---|
1883 | in the debug netCDF file (EXPOUT fields, see section |
---|
1884 | \ref{subsec_namcouplesecond}) always correspond respectively to the |
---|
1885 | field read from and written to the restart file.}. |
---|
1886 | |
---|
1887 | On the 4 figures in this section, short black arrows correspond to |
---|
1888 | {\tt oasis\_put} or {\tt oasis\_get} called in the component |
---|
1889 | that do not lead to any ``put" or receiving action; long black |
---|
1890 | arrows correspond to {\tt oasis\_put} or {\tt oasis\_get} called in |
---|
1891 | the components that do actually lead to a ``put" or ``get'' |
---|
1892 | action; long red arrows correspond to {\tt oasis\_put} or {\tt |
---|
1893 | oasis\_get} called in the component models that lead to a reading |
---|
1894 | or writing of the coupling field from or to a coupling restart file. |
---|
1895 | |
---|
1896 | \begin{enumerate} |
---|
1897 | |
---|
1898 | \item LAG concept first example |
---|
1899 | |
---|
1900 | A first coupling algorithm, exploiting the LAG concept, is |
---|
1901 | illustrated on figure \ref{fig:lag_concept_1}. |
---|
1902 | |
---|
1903 | \begin{figure} |
---|
1904 | \includegraphics[scale=.6]{figures/fig_lag_concept_1} |
---|
1905 | \caption{LAG concept first example} |
---|
1906 | \label{fig:lag_concept_1} |
---|
1907 | \end{figure} |
---|
1908 | |
---|
1909 | During a coupling timestep, model A receives $F_2$ and then sends |
---|
1910 | $F_1$; its timestep length is 4. During a coupling timestep, model B |
---|
1911 | receives $F_1$ and then sends $F_2$; its timestep length is 6. |
---|
1912 | $F_1$ and $F_2$ coupling periods are respectively 12 and 24. If |
---|
1913 | $F_1$/$F_2$ ``put" action by model A/B was used at a coupling |
---|
1914 | timestep to match the model B/A ``get" action, a deadlock would |
---|
1915 | occur as both models would be initially waiting on a ``get" |
---|
1916 | action. To prevent this, $F_1$ and $F_2$ produced at the timestep |
---|
1917 | before have to be used to match respectively the model B and model A |
---|
1918 | ``get" actions. |
---|
1919 | |
---|
1920 | This implies that a lag of respectively 4 and 6 seconds must be |
---|
1921 | defined for $F_1$ and $F_2$. For $F_1$, the {\tt oasis\_put} |
---|
1922 | performed at time 8 and 20 by model A will then lead to ``put" |
---|
1923 | actions (as 8 + 4 = 12 and 20 + 4 = 24 which are coupling periods) |
---|
1924 | that match the ``get" actions performed by {\tt oasis\_get} called by model B |
---|
1925 | at times 12 and 24. For $F_2$, the {\tt oasis\_put} |
---|
1926 | performed at time 18 by model B then leads to a ``put" action (as 18 |
---|
1927 | + 6 = 24 which is a coupling period) that matches the ``get" action |
---|
1928 | performed at time 24 by the {\tt oasis\_get} called by model A. |
---|
1929 | |
---|
1930 | At the beginning of the run, as their LAG index is greater than 0, |
---|
1931 | the first {\tt oasis\_get} of $F_1$ and $F_2$ will automatically be |
---|
1932 | fulfilled with fields read from their respective coupling restart |
---|
1933 | files. The user therefore has to create those coupling restart files |
---|
1934 | before the first run in the experiment. At the end of the run, $F_1$ |
---|
1935 | having a lag greater than 0, is automatically written to its |
---|
1936 | coupling restart file below the last $F_1$ {\tt oasis\_put} as the |
---|
1937 | {\tt date+lag} equals the total run time. The analogue is true for |
---|
1938 | $F_2$. These coupling restart fields will automatically be read in at the beginning |
---|
1939 | of the next run below the respective {\tt oasis\_get}. |
---|
1940 | |
---|
1941 | \item LAG concept second example |
---|
1942 | |
---|
1943 | A second coupling algorithm exploiting the LAG concept is |
---|
1944 | illustrated on figure \ref{fig:lag_concept_2}. During its timestep, |
---|
1945 | model A receives $F_2$, sends $F_3$ and then $F_1$; its timestep |
---|
1946 | length is 6. During its timestep, model B receives $F_1$, receives |
---|
1947 | $F_3$ and then sends $F_2$; its timestep length is also 6. $F_1$, |
---|
1948 | $F_2$ and $F_3$ coupling periods are both supposed to be equal to |
---|
1949 | 12. |
---|
1950 | |
---|
1951 | \begin{figure} |
---|
1952 | \includegraphics[scale=.6]{figures/fig_lag_concept_2} |
---|
1953 | \caption{LAG concept second example} |
---|
1954 | \label{fig:lag_concept_2} |
---|
1955 | \end{figure} |
---|
1956 | |
---|
1957 | For $F_1$ and $F_2$ the situation is similar to the first |
---|
1958 | example. Without any lag specified and without any restart file, a deadlock |
---|
1959 | would occur as both models would be waiting on a ``get" action. To |
---|
1960 | prevent this, $F_1$ and $F_2$ produced at the timestep before have |
---|
1961 | to be used to match the model A and model B ``get" actions, which |
---|
1962 | means that a lag of 6 must be defined for both $F_1$ and $F_2$. For |
---|
1963 | both coupling fields, the {\tt oasis\_put} performed at times 6 and |
---|
1964 | 18 by the source model then lead to ``put" actions (as 6 + 6 = 12 |
---|
1965 | and 18 + 6 = 24 which are coupling periods) that match the ``get" |
---|
1966 | action performed at time 12 and 24 by the {\tt oasis\_get} called |
---|
1967 | by the target model. |
---|
1968 | |
---|
1969 | For $F_3$, sent by model A and received by model B, no lag needs to |
---|
1970 | be defined: the coupling field produced by model A at the coupling |
---|
1971 | timestep can be ``consumed'' by model B without causing a deadlock |
---|
1972 | situation. |
---|
1973 | |
---|
1974 | As in the first example, the {\tt oasis\_get} performed at the |
---|
1975 | beginning of the run for $F_1$ and $F_2$, will automatically receive |
---|
1976 | data read from their coupling restart files, and the last {\tt |
---|
1977 | oasis\_put} performed at the end of the run automatically write |
---|
1978 | them to their coupling restart file. For $F_3$, no coupling restart |
---|
1979 | file is needed. |
---|
1980 | |
---|
1981 | We see here how the introduction of appropriate LAG indices results |
---|
1982 | in receiving in the target component the coupling fields produced by the |
---|
1983 | source component the time step before; this is, in some coupling |
---|
1984 | configurations, essential to avoid deadlock situations. |
---|
1985 | |
---|
1986 | \end{enumerate} |
---|
1987 | |
---|
1988 | \vspace{-0.3cm} |
---|
1989 | \subsection{The sequence concept} |
---|
1990 | \label{subsec_sec} |
---|
1991 | |
---|
1992 | The order of coupling operations in the system is determined solely by |
---|
1993 | the order of calls to send ({\tt oasis\_put} or ``put'') and receive ({\tt oasis\_get} or ``get'') data in the components |
---|
1994 | in conjunction with the setting of the lag in the {\it namcouple}. |
---|
1995 | Data that is received is always blocking while data that is sent is non-blocking with respect to the component making that call. It |
---|
1996 | is possible to deadlock the system if the relative orders of puts and |
---|
1997 | gets in different components are not compatible. |
---|
1998 | |
---|
1999 | With OASIS3-MCT, the sequence (SEQ) index in the {\it namcouple} file |
---|
2000 | now provides the coupling layer with an ability to detect a deadlock |
---|
2001 | before it happens and exit. It does this by tracking the order of get |
---|
2002 | and put calls in components compared to the SEQ specified in the {\it |
---|
2003 | namcouple}. If there are any inconsistencies, the component will abort |
---|
2004 | gracefully with a useable error message before the system deadlocks. |
---|
2005 | If there are any coupling dependencies in the system, use of the SEQ |
---|
2006 | index is recommended for diagnosis but has no impact on the ultimate |
---|
2007 | solution and is NOT required. |
---|
2008 | |
---|
2009 | In the following two examples, there are two |
---|
2010 | models, each ``put" a field to the other at every coupling period |
---|
2011 | without any lags. In the first case, there is no dependency as each |
---|
2012 | model first sends and then receives some data. |
---|
2013 | |
---|
2014 | \begin{verbatim} |
---|
2015 | model1 model2 |
---|
2016 | ------ ------ |
---|
2017 | put(fld1) put(fld2) |
---|
2018 | get(fld2) get(fld1) |
---|
2019 | \end{verbatim} |
---|
2020 | |
---|
2021 | In this |
---|
2022 | case, there is no sequencing dependency and the value of SEQ must be |
---|
2023 | identical (or unset) in the {\it namcouple} description of the fld1 |
---|
2024 | and fld2 coupling. If by mistake, SEQ is set to 1 for fld1 and 2 for fld2, |
---|
2025 | then the coupled model will abort because at runtime, the coupler will |
---|
2026 | detect in model 2 that fld2 was sent before fld1 was received which |
---|
2027 | is out of sequence as defined by the SEQ settings. |
---|
2028 | |
---|
2029 | In the next example, there is a dependency in the sequencing. |
---|
2030 | |
---|
2031 | \begin{verbatim} |
---|
2032 | model1 model2 |
---|
2033 | ------ ------ |
---|
2034 | put(fld1) get(fld1) |
---|
2035 | fld2=g(fld1) |
---|
2036 | get(fld2) put(fld2) |
---|
2037 | \end{verbatim} |
---|
2038 | |
---|
2039 | In model2, fld2 depends on fld1. If SEQ is not used and if, for example, model1 does not have the |
---|
2040 | consistent ordering of the put and get shown above (required by model2), then the models would deadlock and hang. If this dependency is known, there is a benefit in setting SEQ=1 for fld1 and SEQ=2 for fld2; at |
---|
2041 | runtime, if the sequencing of model1 or model2 does not match the |
---|
2042 | above diagram, then the coupling layer will detect it and will exit gracefully with an error message. |
---|
2043 | |
---|
2044 | Again, the SEQ namecouple setting is only diagnostic and is not |
---|
2045 | required. |
---|
2046 | |
---|
2047 | |
---|
2048 | |
---|
2049 | |
---|
2050 | |
---|