<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<title>Re: [mpas-developers] MPAS I/O requirements and design doc</title>
</head>
<body>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"><br>
Michael,<br>
<br>
Finally read your I/O doc and have a several comments/suggestions.<br>
<br>
For requirements, I would add:<br>
- requirement for exact restart (any simulation interrupted by a restart must be bitwise identical to a simulation without restart)<br>
- for CESM, netCDF CF conventions are required for output files (mostly certain required metadata – don’t think we need to be bound by CF grid conventions yet since they are a bit onerous, especially for unstructured grids)<br>
- requirement to be able to specify the number of I/O tasks; this will be important to optimize the I/O layer with underlying architecture<br>
- requirement to write many different types of fields, including scalars and various multi-dimensional arrays (eg meridional diagnostics, transports, surface fields), some of which we are not likely to want in the registry (temporary derived diagnostic fields).
Note that even the scalars count as a field since they may have associated metadata (eg transport diagnostics with the name/units/possible location info for the transport).<br>
<br>
For global attributes, you will need a more complete stream attribute layer with the stream having an arbitrary number of attributes. Some of these may be standard (eg conventions, history). You will not only need to read/write but also add/remove attributes
to a stream.<br>
<br>
Similarly, you will need a more robust attribute layer for fields – you can either do this within the Field data type or define a new IOField data type that includes arrays of attributes together with the field. Basically, you will need to allow the user to
define an arbitrary number of attributes of any kind (string, int, real, double, logical) for a given field, including standard attributes like short name, long name, units, valid range, undefined, etc. Having this as part of the field layer can be beneficial
for defining many attributes only once near start-up or reusing the same field in many different streams.<br>
<br>
You might also want to separate the dimension layer (you already sort of have this in the io_info within Field) so you can separately define dimensions and attach them to fields. CESM will eventually want an unlimited (time) dimension too, but we can worry
about that later.<br>
<br>
For netCDF (or other self-defining formats), you will need multiple phases, especially for writing:<br>
- creating the fields and adding all attributes<br>
- “defining” the fields and dimensions (netCDF has a separate define phase that writes all attributes and prepares for the binary portion and it’s very inefficient to jump in and out of the define phase)<br>
- writing the field (generally writing the actual data since most metadata is written during the define phase)<br>
<br>
For performance/memory reasons, you don’t want to have to gather/copy data during the first two phases since you’ll need to define all fields up front. So the field should probably use a pointer with which you can point to the actual binary data just before
reading/writing.<br>
<br>
Are we going to support straight binary format? If so, we’ll need a design for how we store metadata in those files. Note that I don’t think this is a strong need any more (netCDF can not always guarantee exact restart if an architecture isn’t using a form
of IEEE binary format, but that doesn’t happen very often anymore).<br>
<br>
Basically, the current design is not complete enough, esp. wrt attributes, and should probably be fleshed out some more. We can always prioritize aspects of the implementation so we can at least get multi-block I/O for registry variables, etc. up quickly.
But we’ll need all of this before too long.<br>
<br>
Sorry to add more work, but it’s worth thinking about this stuff now.<br>
<br>
Phil<br>
<br>
<br>
On 2/24/12 2:08 PM, "Michael Duda" <<a href="duda@ucar.edu">duda@ucar.edu</a>> wrote:<br>
<br>
</span></font>
<blockquote><span style="font-size:12pt"><font face="Courier, Courier New">Hi, Folks.<br>
<br>
I've been slowly working on a requirements and design document for<br>
a new I/O layer in MPAS that will provide parallel I/O (almost<br>
certainly to be implemented using PIO) and I/O for multiple blocks<br>
per MPI task. The Implementation and Testing chapters are still<br>
blank, as I first wanted to get some feedback on the requirements<br>
and proposed design to see whether I'm headed in the right<br>
direction.<br>
<br>
Attached is the document and its source; if anyone has questions,<br>
comments, or other suggestions, I'd be glad to hear them.<br>
<br>
Thanks!<br>
Michael<br>
<hr align="CENTER" size="3" width="95%">
_______________________________________________<br>
mpas-developers mailing list<br>
<a href="mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
<a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
</font></span></blockquote>
<span style="font-size:12pt"><font face="Courier, Courier New"><br>
<br>
---<br>
Correspondence/TSPA/DUSA EARTH<br>
------------------------------------------------------------<br>
Philip Jones <a href="pwjones@lanl.gov">pwjones@lanl.gov</a><br>
Climate, Ocean and Sea Ice Modeling<br>
Los Alamos National Laboratory<br>
T-3 MS B216 Ph: 505-500-2699<br>
PO Box 1663 Fax: 505-665-5926<br>
Los Alamos, NM 87545-1663<br>
</font></span><font size="1"><font face="Helvetica, Verdana, Arial"><span style="font-size:9pt"><br>
<br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"><br>
</span></font>
</body>
</html>