| 2 |
% $Name$ |
% $Name$ |
| 3 |
|
|
| 4 |
|
|
| 5 |
\section{Fortran Binary I/O: MDSIO and RW} |
\section{Fortran Native I/O: MDSIO and RW} |
| 6 |
\label{sec:mdsio_and_rw} |
\label{sec:mdsio_and_rw} |
| 7 |
|
|
| 8 |
|
|
| 11 |
\begin{rawhtml} |
\begin{rawhtml} |
| 12 |
<!-- CMIREDIR:package_mdsio: --> |
<!-- CMIREDIR:package_mdsio: --> |
| 13 |
\end{rawhtml} |
\end{rawhtml} |
|
\label{sec:pkg:rw} |
|
| 14 |
|
|
| 15 |
\subsubsection{Introduction} |
\subsubsection{Introduction} |
| 16 |
The \texttt{mdsio} package contains a group of Fortran routines |
The \texttt{mdsio} package contains a group of Fortran routines |
| 18 |
(``binary'') Fortran files. The \texttt{mdsio} routines are used by |
(``binary'') Fortran files. The \texttt{mdsio} routines are used by |
| 19 |
the \texttt{rw} package. |
the \texttt{rw} package. |
| 20 |
|
|
| 21 |
|
The \texttt{mdsio} package is currently the primary method for MITgcm |
| 22 |
|
I/O, but it is not being actively extended or enhanced. Instead, the |
| 23 |
|
\texttt{mnc} netCDF package (see Section \ref{sec:pkg:mnc}) is |
| 24 |
|
expected to gain all of the current \texttt{mdsio} functionality and, |
| 25 |
|
eventually, replace it. For the short term, every effort has been |
| 26 |
|
made to allow \texttt{mnc} and \texttt{mdsio} to peacefully co-exist. |
| 27 |
|
In may cases, the model can read one format and write to the other. |
| 28 |
|
This side-by-side functionality can be used to, for instance, help |
| 29 |
|
convert pickup files or other data sets between the two formats. |
| 30 |
|
|
| 31 |
|
|
| 32 |
\subsubsection{Using MDSIO} |
\subsubsection{Using MDSIO} |
| 33 |
The \texttt{mdsio} package is geared toward the reading and writing of |
The \texttt{mdsio} package is geared toward the reading and writing of |
| 34 |
floating point (Fortran \texttt{REAL*4} or \texttt{REAL*8}) arrays. |
floating point (Fortran \texttt{REAL*4} or \texttt{REAL*8}) arrays. |
| 140 |
``fit'' within these assumed sizes can be challenging to read or |
``fit'' within these assumed sizes can be challenging to read or |
| 141 |
write with \texttt{mdsio}. |
write with \texttt{mdsio}. |
| 142 |
|
|
| 143 |
\item[Tiling] or domain decomposition is, for logically rectangular |
\item[Tiling] or domain decomposition is automatically handled by |
| 144 |
grid topologies and ``standard'' cubesphere topologies, gracefully |
\texttt{mdsio} for logically rectangular grid topologies |
| 145 |
handled by \texttt{mdsio}. The \texttt{mdsio} package can, without |
(\textit{eg.} lat-lon grids) and ``standard'' cubesphere topologies. |
| 146 |
any coding changes, read and write to/from files that were run on |
More complicated topologies will probably not be supported. The |
| 147 |
the same global grid but with different tiling (grid decomposition) |
\texttt{mdsio} package can, without any coding changes, read and |
| 148 |
schemes. For example, \texttt{mdsio} can use and/or create |
write to/from files that were run on the same global grid but with |
| 149 |
identical input/output files for a ``C32'' cube when the model is |
different tiling (grid decomposition) schemes. For example, |
| 150 |
run with either 6, 12, or 24 tiles (corresponding to 1, 2 or 4 tiles |
\texttt{mdsio} can use and/or create identical input/output files |
| 151 |
per cubesphere face). Currently, this is one of the primary |
for a ``C32'' cube when the model is run with either 6, 12, or 24 |
| 152 |
advantages that the \texttt{mdsio} package has over \texttt{mnc}. |
tiles (corresponding to 1, 2 or 4 tiles per cubesphere face). |
| 153 |
|
Currently, this is one of the primary advantages that the |
| 154 |
\item[Meta-data] is written on a per-file basis using a second file |
\texttt{mdsio} package has over \texttt{mnc}. |
| 155 |
with a \texttt{.meta} extension as described above. One should be |
|
| 156 |
careful not to delete the metadata files when using convenient |
\item[Single-CPU I/O] can be specified with the flag |
| 157 |
MatLAB post-processing scripts such as \texttt{rdmds()}. |
\begin{verbatim} |
| 158 |
|
useSingleCpuIO = .TRUE., |
| 159 |
|
\end{verbatim} |
| 160 |
|
in the \texttt{PARM01} namelist within the main \texttt{data} file. |
| 161 |
|
Single--CPU I/O mode is appropriate for computers (\textit{eg.} some |
| 162 |
|
SGI systems) where it can either speed overall I/O or solve problems |
| 163 |
|
where the operating system or file systems cannot correctly handle |
| 164 |
|
multiple threads or MPI processes simultaneously writing to the same |
| 165 |
|
file. |
| 166 |
|
|
| 167 |
|
\item[Meta-data] is written by MITgcm on a per-file basis using a |
| 168 |
|
second file with a \texttt{.meta} extension as described above. |
| 169 |
|
MITgcm itself does not read the \texttt{*.meta} files, they are |
| 170 |
|
there primarly for convenience during post-processing. One should |
| 171 |
|
be careful not to delete the meta-data files when using MatLAB |
| 172 |
|
post-processing scripts such as \texttt{rdmds()} since it relies |
| 173 |
|
upon them. |
| 174 |
|
|
| 175 |
\item[Numerous files] can be written by \texttt{mdsio} due to its |
\item[Numerous files] can be written by \texttt{mdsio} due to its |
| 176 |
typically per-time-step and per-variable orientation. The creation of |
typically per-time-step and per-variable orientation. The creation of |
| 177 |
both a binary (\texttt{*.data}) and ASCII text meta--data |
both a binary (\texttt{*.data}) and ASCII text meta-data |
| 178 |
(\texttt{*.meta}) file for each output type step tends to exacerbate |
(\texttt{*.meta}) file for each output type step tends to exacerbate |
| 179 |
the problem. Some (mostly, older) operating systems do not |
the problem. Some (mostly, older) operating systems do not |
| 180 |
gracefully handle large numbers (\textit{eg.} many thousands) of |
gracefully handle large numbers (\textit{eg.} many thousands) of |
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch