/[MITgcm]/manual/s_outp_pkgs/text/mdsio.tex
ViewVC logotype

Diff of /manual/s_outp_pkgs/text/mdsio.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph | View Patch Patch

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