Added FlexIO documentation in HTML format.

Taken from the (almost forgotten) repository /afs/aei/cvsroot/IEEEIO/doc. Should be the same as on http://zeus.ncsa.uiuc.edu/~jshalf/FlexIO/. git-svn-id: http://svn.cactuscode.org/arrangements/CactusExternal/FlexIO/trunk@50 21a6bef8-4479-4f54-8f8d-0db94a2919ef
author: tradke <tradke@21a6bef8-4479-4f54-8f8d-0db94a2919ef> 2003-08-06 12:23:27 +0000
committer: tradke <tradke@21a6bef8-4479-4f54-8f8d-0db94a2919ef> 2003-08-06 12:23:27 +0000
commit: bf0225505894535a9ae36f02a3f6efa6642c5c00 (patch)
tree: 822a739d2aa7568d819e634ced6e26035991b1ef
parent: dfcc3d15b8728f2827b323a77e3f8a9e57ca9904 (diff)
29 files changed, 4250 insertions, 10 deletions
diff --git a/doc/documentation.tex b/doc/documentation.tex
index 5ddaefa..02fc640 100644
--- a/doc/documentation.tex
+++ b/doc/documentation.tex
@@ -1,7 +1,7 @@
 \documentclass{article}
 
 % Use the Cactus ThornGuide style file
-% (Automatically used from Cactus distribution, if you have a 
+% (Automatically used from Cactus distribution, if you have a
 %  thorn without the Cactus Flesh download this from the Cactus
 %  homepage at www.cactuscode.org)
 \usepackage{../../../../doc/ThornGuide/cactus}
@@ -9,7 +9,7 @@
 \begin{document}
 
 \title{FlexIO}
-\author{Thomas Radke, John Shalf}
+\author{John Shalf}
 \date{$ $Date$ $}
 
 \maketitle
@@ -19,7 +19,7 @@
 
 \section{Purpose}
 
-Thorn FlexIO provides a library for writing multidimensional data from 
+Thorn FlexIO provides a library for writing multidimensional data from
 Cactus using the IEEEIO data format. The advantage of using this library
 is that it is distributed with Cactus and needs no additional libraries
 to be installed on a machine.
@@ -53,20 +53,19 @@ MPIO interface provides access to parallel IO for MPI codes.
 
 \section{More Information}
 
-For more information the reader is directed to the web pages for 
+For more information the reader is directed to the web pages for
 FlexIO at
-{\tt http://infinite-entropy.lbl.gov/FlexIO/}
+\begin{itemize}
+  \item \verb|http://infinite-entropy.lbl.gov/FlexIO/|
+  \item \verb|http://zeus.ncsa.uiuc.edu/~jshalf/FlexIO/|
+  \item in the thorn's directory \verb|CactusExternal/FlexIO/doc/html/|
+\end{itemize}
 
 Information can be found on these web pages about
-
 \begin{itemize}
-
   \item{} Programming interfaces, including C, C++ and Fortran
- 
   \item{} Utilities, for finding information about IEEEIO data files
-
   \item{} Data converters, between IEEEIO and HDF
-
 \end{itemize}
 
 % Do not delete next line
diff --git a/doc/html/AMRfileReader.html b/doc/html/AMRfileReader.html
new file mode 100644
index 0000000..21749b3
--- /dev/null
+++ b/doc/html/AMRfileReader.html
@@ -0,0 +1,157 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>AmrFileReader</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+   <font face="arial,helvetica"> <h1>AmrFileReader</h1></font>
+
+    The <a href="AmrGridReader">AmrGridReader</a> only provides
+    unfiltered access to the grids stored in the AMR datafile.  For a
+    real visualization application, it is necessary to filter through
+    these grids to present only what is relevant for a particular
+    domain and timestep.  The <b>AmrFileReader</b> provides that sort
+    of filtering capability.<p>
+      The <b>AmrFileReader</b> selects all grids that are active at a
+      particular timestep in the evolution sequence.  It also allows
+      you to mask out sets of levels (for example only show levels 1-3 
+      of a 7 level hierarchy).  Since the stepping of grids proceeds
+      at different paces at different levels, the timestep is a global 
+      quantity that refers to the finest granularity of stepping that
+      can occur during the evolution (the integer timesteps of the
+      deepest level of refinement).  The API is intelligent enough to
+      only reload data from grids that have changed when a different
+      timestep has been selected since deeper-level grids will change
+      more rapidly than their parent grids.<p>
+    <hr>
+       <font face="arial,helvetica" color="#555588"><h2>The API</h2></font>
+    <UL>
+      <LI><a href="#CPP">C++ Interface</a>
+      <LI><a href="#C">C Interface</a>
+      <LI><a href="#F77">F77/F90 Interface</a>
+    </UL>
+    <hr>
+    <u><h2><a name="CPP">C++ Interface</a></h2></u>
+    <DL>
+      <DT><font color="#888888"><b>Constructors/Destructors</b></font>
+    <DL>
+      <DT><b>AmrFileReader::AmrFileReader(IObase
+	  &filehandle)</b> <i>constructor</i>
+      <DD>The <i>filehandle</i> is an already
+	<a href="UsingC++.html#Opening">open IEEEIO or HDFIO
+	  file</a>.  This initializes the reader and attaches it to that
+	datafile.
+      <DT><b>AmrFileReader::~AmrFileReader()</b> <i>destructor</i>
+      <DD>This flushes all of the necessary file buffers.
+	The filehandle that the reader was bound to must be
+	closed separately though.
+    </DL>
+    <DT><font color="#888888"><b>Queries about File Contents</b></font>
+    <DL>
+      <DT><b>int AmrFileReader::nLevels()</b>
+      <DD>Returns the number of levels in the AMR hierarchy.  This is
+	the deepest the hierarchy gets in this particular datafile as
+	opposed to the number of levels present at this time in the
+	evolution (this distinction is important for adaptive depth
+	schemes where the number of levels will change depending on
+	the demands of the solver).
+      <DT><b>AmrFileReader::getTimeRange(int &mintime,int &maxtime)</b>
+      <DD>Gets the range of integer timesteps stored in the file.
+	The nonzero mintime exists to support schemes where the
+	evolution is broken up among several files.
+    </DL>
+    <DT><font color="#888888"><b>Filters</b></font>
+      <DT>The <i><b>filter</b></i> methods listed below select grids based on 
+	the criteria of time and level number.  Grids selected by the
+	filter are referred to as <i><b>active grids</b></i>.<p>
+    <DL>
+      <DT><b>AmrFileReader::setTime(int time)</b>
+      <DD>Sets the current timestep to select the data hierarchy for.
+	The timestep is defined with respect to the rate at which
+	grids change at the deepest level of the AMR hierarchy stored
+	in the file.  Selecting a particular timestep selects a
+	snapshot of the hieararchy at a particular time in the
+	evolution.
+	<DT><b>AmrFileReader::hideLevel(int level)</b>
+	<DD>By default all levels are visible and are read in when the 
+	<code>getGrids()</code> method is called.  You can hide
+	individual levels using this method.  This is useful when
+	loading the entire hierarchy is either too confusing, too slow, or too
+	large for the workstation to handle.
+	<DT><b>AmrFileReader::showLevel(int level)</b>
+	<DD>Shows a level that has otherwise been hidden.
+	<DT><b>AmrFileReader::showAllLevels()</b>
+	<DD>A convenience method for making all of the levels visible.
+    </DL>
+     <DT><font color="#888888"><b>Getting the Data</b></font>
+      <DL>	
+      <DT><b>int AmrFileReader::getGrids(FlexArray&ltAmrGrid&gt &g)</b>
+      <DD>Gets all currently active grids and puts them into a
+	FlexArray of 
+	<a href="AmrGrid.html">AmrGrid</a> datastructures. An
+	<i>active grid</i> is one that is currently selected by the
+	<code>setTime()</code> and <code>show/hideLevel()</code> filters.  The
+	FlexArray is a simple template class for arrays that grow
+	automatically to accomodate new elements.  If you or your
+	compiler do not like templates, then you can use the two-step
+	static allocation method
+	(<code>getNumGrids()</code>/<code>getGrids()</code>) defined
+	below.
+	This method returns the number of active grids.
+      <DT><b>int AmrFileReader::getNumGrids()</b>
+      <DD>Returns the total number of active grids currently selected
+	by the 	<code>setTime()</code> and
+	<code>show/hideLevel()</code> 
+	filters.  This is used to determine how 
+	large of an array of AmrGrid structures to allocate in order
+	to receive the data using the <code>getGrids()</code> method
+	call since this array length is static.
+      <DD><b>int AmrFileReader::getGrids(AmrGrid *grids)</b>
+      <DD>This method reads the grid information and data for all
+	currently active grids into the pre-allocated array of 
+	<code>grids</code> passed to it.  The API will allocate memory 
+	for the grids upon reading the data, but it is the responsibility of
+	the programmer to dispose of the array of grids and the data
+	stored within these datastructures once they are done with it.
+    </DL>
+    <DT><font color="#888888"><b>Utility and Debugging Methods</b></font>
+      <DT><DL>
+      <DT><b>AmrFileReader::setDataLoadingOff()</b>   
+      <DD>This causes the <code>getGrids()</code> methods
+	to read in the informational part of 
+	the AmrGrid datastructures, but not load any data.  This is
+	useful for just aquiring bounding box information or
+	estimating the memory/computational requirements for loading
+	the entire hierarchy.
+      <DT><b>AmrFileReader::setDataLoadingOn()</b>   
+      <DD>This causes the <code>getGrids()</code> methods
+	to read both the informational and data part of 
+	the AmrGrid datastructures.  This is the default state for
+	this API.
+      <DT><b>printGridInfo()</b>
+      <DD>Prints information about all grids in file to STDERR.  Used
+	only for debugging.
+      <DT><b>printActiveGrids()</b>
+      <DD>Prints information about all <b>active</b> grids to STDERR.
+	Used only for debugging.
+	<DT><b>int debug</b>
+	This is a public variable that can be set to a nonzero value
+	in order to print additional debugging information for each
+	method call.  This printing is turned off when it is set to zero.
+    </DL>
+  </DL>
+    <hr>
+    <h2><u><a name="C">C Interface</a></u></h2>
+    Not ready yet.
+    <hr>
+    <h2><u><a name="F77">F77/F90 Interface</a></u></h2>
+    Not ready yet.
+    <hr>
+    <address><a href="mailto:jshalf@ariel.ncsa.uiuc.edu"></a></address>
+<!-- Created: Thu Feb  4 10:03:12 CST 1999 -->
+<!-- hhmts start -->
+Last modified: Thu Feb  4 17:49:33 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/AMRreaderBase.html b/doc/html/AMRreaderBase.html
new file mode 100644
index 0000000..7f3d1ea
--- /dev/null
+++ b/doc/html/AMRreaderBase.html
@@ -0,0 +1,100 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>Basic AMR Reader</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+    <font face="arial,helvetica"><h1>Basic AMR Reader</h1></font>
+    This reads the file format written by the 
+    <a href="AMRwriter.html">AMRwriter API</a>.  It does not care if
+    the underlying file format is <a href="IEEEIO.html">IEEEIO</a> or 
+    <a href="http://hdf.ncsa.uiuc.edu">HDF-SDS/NetCDF</a>.<p>
+      This very simplistic API reads information about each grid
+      stored in the AMR file into a list of
+      <a href="AmrGrid.html">AmrGrid datastructures</a> without
+      actually loading the associated grid data.  The user can
+      then use this information to tell the AMRreader which grids to
+      load data for.  The higher-level <a href="AMRfileReader.html">AmrFileReader</a> 
+      provides its own filtering system for selecting grids by level
+      and timestep.  At this time only a C++ interface is released.
+      C and F77 interfaces are available on request.<p>
+      <hr>
+       <font face="arial,helvetica" color="#555588"><h2>The API</h2></font>
+    <UL>
+      <LI><a href="#CPP">C++ Interface</a>
+      <LI><a href="#C">C Interface</a>
+      <LI><a href="#F77">F77/F90 Interface</a>
+    </UL>
+    <hr>
+     <u><h3><a name="CPP">C++ Interface</a></h3></u>
+    <DL>
+      <DT><font color="#888888"><b>Constructors/Destructors</b></font>
+      <DD><DL>
+	  <DT><b>AmrGridReader::AmrGridReader(IObase
+		&filehandle)</b> <i>constructor</i>
+	  <DD>The <i>filehandle</i> is an already
+	    <a href="UsingC++.html#Opening">open IEEEIO or HDFIO
+	    file</a>.  This initializes the reader and attaches it to that
+	    datafile.
+	  <DT><b>AmrGridReader::~AmrGridReader()</b> <i>destructor</i>
+	  <DD>This flushes all of the necessary file buffers.
+	    The filehandle that the writer was bound to must be
+	    closed separately though.
+	</DL><p>
+      <DT><font color="#888888"><b>Reading/Stepping through the
+	    Data</b></font><br>
+	<DD>
+	Grids are indexed from 0 to nDatasets-1 (where nDatasets are
+	the total number of grids stored in the file).  The grids are
+	indexed in exactly the order they are stored in the file
+	(there is no sorting of indices here).  So its up to the user
+	of the API to use the <a href="AmrGrid.html">AmrGrid</a>
+	datastructures to select which grids to actually load data for.<p>
+	There are two different types of <i>"get"</i> requests that
+	can be filled.  When you <i>"getGridInfo"</i>, only the
+	informational portions of the 
+	<a href="AmrGrid.html">AmrGrid</a> datastructure are filled
+	out.  When you <i>"getGridData"</i> then both the
+	grid information and associated data will be loaded into the
+	<a href="AmrGrid.html">AmrGrid</a> datastructure.<p>
+      <DT><DL>
+      <DT><b>AmrGrid *AmrGridReader::getGridInfo(AmrGrid &grid,int index)</b>
+      <DD>Fills out the informational portions of the 
+		<a href="AmrGrid.html">AmrGrid</a> datastructure.
+	The <code>data</code> member of the structure is left NULL.  Returns 
+	a pointer to the AmrGrid if it is successful and a NULL if it fails.
+      <DT><b>AmrGrid *AmrGridReader::getGridData(AmrGrid &grid,int index)</b>
+      <DD>Fills out the informational portions of the
+	<a href="AmrGrid.html">AmrGrid</a> datastructure and also
+	loads the associated grid data into the <code>data</code> member of
+	the AmrGrid datastructure.  If the <code>data</code> member is NULL, 
+	it will allocate storage for it (which the user is responsible 
+	for freeing), otherwise it will load the data directly into
+	existing storage pointed to by that member.  Returns pointer
+	to the AmrGrid if it is successful and returns NULL if it fails.
+      <DT><b>AmrGrid *AmrGridReader::getGrid(AmrGrid &grid,int index)</b>
+      <DD>Performs the same function as 
+	<code>AmrGridReader::getGridData()</code>.  Just a more
+	convenient name.
+      <DT><b>AmrGrid *AmrGridReader::getGrid(int index)</b>
+      <DD>Performs the same function as 
+	<code>AmrGridReader::getGridData()</code> except that it
+	allocates a new AmrGrid datastructure to store the information 
+	and data in.  The user is responsible for freeing this
+	structure when they are done with it though.
+    </DL>
+    <hr>
+    <h3><u><a name="C">C Interface</a></u></h3>
+    Not ready for primetime yet but available on request.
+    <hr>    
+    <h3><u><a name="F77">F77/F90 Interface</a></u></h3>
+    Not ready for primetime yet but available on request.
+    <hr>
+    <address><a href="mailto:jshalf@ariel.ncsa.uiuc.edu"></a></address>
+<!-- Created: Wed Feb  3 22:06:21 CST 1999 -->
+<!-- hhmts start -->
+Last modified: Thu Feb  4 15:45:03 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/AMRucdReader.html b/doc/html/AMRucdReader.html
new file mode 100644
index 0000000..6bad528
--- /dev/null
+++ b/doc/html/AMRucdReader.html
@@ -0,0 +1,142 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>AMR-UCD Reader</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+    <h1>AMR-UCD Reader</h1>
+
+    Most visualization systems have no provisions for handling AMR
+    data.  One solution is to resample all of the grids into a single
+    uniform sized grid.  However for even a 7 level hierarchy, the
+    unigrid becomes far too large to be manageable and still retain
+    the fidelity of the original data.  A second solution is use
+    unigrid visualization algorithms on each grid in the hierarchy and 
+    then superimpose them on one-another.  In this case geometries
+    from the coarser resolution datasets occlude the finer-resolution
+    geometry. An alternative solution is to convert the data into
+    hexahedral cells with the overlaps between parent levels and the
+    children are eliminated.  This provides multi-resolution fidelity which
+    matches the nature of the original data but allows it to be
+    visualized using standard off-the-shelf visualizaton tools.<p>
+      
+      The <code>AmrUcdFileReader</code> inherits directly from the
+      <code><a href="AMRfileReader.html">AmrFileReader</a></code> and
+      all methods from its base class are public.  They will be
+      listed again here for convenience.  The only method (aside from
+      the constructor/destructor) that is contributed by this class is 
+      the <a name="#GETUCD">getUcd()</a> method.<p>
+      
+       <hr>
+       <font face="arial,helvetica" color="#555588"><h2>The API</h2></font>
+    <UL>
+      <LI><a href="#CPP">C++ Interface</a>
+      <LI><a href="#C">C Interface</a>
+      <LI><a href="#F77">F77/F90 Interface</a>
+    </UL>
+    <hr>
+    <u><h3><a name="CPP">C++ Interface</a></h3></u>
+    <DL>
+      <DT><font color="#888888"><b>Constructors/Destructors</b></font>
+    <DL>
+      <DT><b>AmrUcdFileReader::AmrUcdFileReader(IObase
+	  &filehandle)</b> <i>constructor</i>
+      <DD>The <i>filehandle</i> is an already
+	<a href="UsingC++.html#Opening">open IEEEIO or HDFIO
+	  file</a>.  This initializes the reader and attaches it to that
+	datafile.
+      <DT><b>AmrUcdFileReader::~AmrUcdFileReader()</b> <i>destructor</i>
+      <DD>This flushes all of the necessary file buffers.
+	The filehandle that the reader was bound to must be
+	closed separately though.
+    </DL>
+    <DT><font color="#888888"><b>Queries about File Contents</b></font>
+    <DL>
+      <DT><b>int AmrUcdFileReader::nLevels()</b>
+      <DD>Returns the number of levels in the AMR hierarchy.  This is
+	the deepest the hierarchy gets in this particular datafile as
+	opposed to the number of levels present at this time in the
+	evolution (this distinction is important for adaptive depth
+	schemes where the number of levels will change depending on
+	the demands of the solver).
+      <DT><b>AmrUcdFileReader::getTimeRange(int &mintime,int &maxtime)</b>
+      <DD>Gets the range of integer timesteps stored in the file.
+	The nonzero mintime exists to support schemes where the
+	evolution is broken up among several files.
+    </DL>
+    <DT><font color="#888888"><b>Filters</b></font>
+      <DT>The <i><b>filter</b></i> methods listed below select grids based on 
+	the criteria of time and level number.  Grids selected by the
+	filter are referred to as <i><b>active grids</b></i>.<p>
+    <DL>
+      <DT><b>AmrUcdFileReader::setTime(int time)</b>
+      <DD>Sets the current timestep to select the data hierarchy for.
+	The timestep is defined with respect to the rate at which
+	grids change at the deepest level of the AMR hierarchy stored
+	in the file.  Selecting a particular timestep selects a
+	snapshot of the hieararchy at a particular time in the
+	evolution.
+	<DT><b>AmrUcdFileReader::hideLevel(int level)</b>
+	<DD>By default all levels are visible and are read in when the 
+	<code>getGrids()</code> method is called.  You can hide
+	individual levels using this method.  This is useful when
+	loading the entire hierarchy is either too confusing, too slow, or too
+	large for the workstation to handle.
+	<DT><b>AmrUcdFileReader::showLevel(int level)</b>
+	<DD>Shows a level that has otherwise been hidden.
+	<DT><b>AmrUcdFileReader::showAllLevels()</b>
+	<DD>A convenience method for making all of the levels visible.
+    </DL>
+     <DT><font color="#888888"><b>Getting the UCD Data</b></font>
+      <DL>	
+      <DT><b>int AmrUcdFileReader::getUcd(FlexArray&ltAmrNode*&gt
+	  &nodes, FlexArray&ltint&gt &cells)</b>
+      <DD>Gets all currently active grids and converts them into a
+	finite element form composed of hexahedral cells.  The node
+	list contains the coordinates of the vertices of the cells and 
+	the cell list contains the connectivity of the hexahedral
+	cells (indexed into the nodes list where the first element is
+	an index of <i>0</i> and the last is <i>NumNodes-1</i>).
+    </DL>
+    <DT><font color="#888888"><b>Utility and Debugging Methods</b></font>
+      <DT><DL>
+      <DT><b>AmrUcdFileReader::setDataLoadingOff()</b>   
+      <DD>This causes the <code>getGrids()</code> methods
+	to read in the informational part of 
+	the AmrGrid datastructures, but not load any data.  This is
+	useful for just aquiring bounding box information or
+	estimating the memory/computational requirements for loading
+	the entire hierarchy.
+      <DT><b>AmrUcdFileReader::setDataLoadingOn()</b>   
+      <DD>This causes the <code>getGrids()</code> methods
+	to read both the informational and data part of 
+	the AmrGrid datastructures.  This is the default state for
+	this API.
+      <DT><b>printGridInfo()</b>
+      <DD>Prints information about all grids in file to STDERR.  Used
+	only for debugging.
+      <DT><b>printActiveGrids()</b>
+      <DD>Prints information about all <b>active</b> grids to STDERR.
+	Used only for debugging.
+	<DT><b>int debug</b>
+	This is a public variable that can be set to a nonzero value
+	in order to print additional debugging information for each
+	method call.  This printing is turned off when it is set to zero.
+    </DL>
+  </DL>
+    <hr>
+    <h3><u><a name="C">C Interface</a></u></h3>
+    Not ready yet.
+    <hr>
+    <h3><u><a name="F77">F77/F90 Interface</a></u></h3>
+    Not ready yet.
+      
+    <hr>
+    <address><a href="mailto:jshalf@ariel.ncsa.uiuc.edu"></a></address>
+<!-- Created: Thu Feb  4 20:37:32 CST 1999 -->
+<!-- hhmts start -->
+Last modified: Thu Feb  4 21:31:06 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/AMRwriter.html b/doc/html/AMRwriter.html
new file mode 100644
index 0000000..7c3ec94
--- /dev/null
+++ b/doc/html/AMRwriter.html
@@ -0,0 +1,395 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<!-- </td><td valign=top><br><br><font face="arial,helvetica"color="#555588"><h2 align=left> Visualization and Virtual Environments</h2></font><p></td></tr> -->
+
+<html>
+  <head>
+    <title>AMR Writer</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+    <font face="arial,helvetica"><h1>AMR Writer</h1></font>
+    This writer stores additional information to fully define and
+    AMR grid heirarchy that evolves through time. Currently it
+    accepts integer grid coordinate definitions and generates
+    floating-point positions internally.  However, this interface
+    will be extended to do the reverse for people who's codes use a
+    floating-point representation of grid positions for internal
+    storage.<p>
+      
+      <font face="arial,helvetica" color="#555588"><h2>Attribute Specification</h2></font>
+      The following NetCDF-style attributes are added to each
+      dataset to fully describe its position in the heirarchy.
+      A <b>grid</b> is one of the dataset blocks in the heirarchy.
+      These tags are applied to each grid in the heirarchy 
+      to uniquely identify it.
+    <h4>real-valued attributes</h4>
+    <dl><DD>
+	<DL>
+	  <DT><b>origin</b>
+	  <DD>The floating-point origin of the dataset.
+	  <DT><b>delta</b>
+	  <DD>The physical spacing between grid points in the dataset.
+	  <DT><b>min_ext</b>
+	  <DD>The minimum coordinate of the dataset in physical space.  
+	    This is actually identical to the <b>origin</b>.
+	  <DT><b>max_ext</b>
+	  <DD>The maximum coordinate of the dataset in physical space.
+	  <DT><b>time</b>
+	  <DD>The current real-valued time that this grid represents.
+	</DL>
+    </dl>
+    <h4>integer-valued attributes</h4>
+    <dl><DD>
+	<DL>
+	  <DT><b>level</b>
+	  <DD>The level of this grid in the amr heirarchy.  Levels are
+	    numbered from 0-to-(nlevels-1).
+	  <DT><b>timestep</b>
+	  <DD>The integer timestep in the file.  This is with respect to
+	    the evolution of the finest-resolution grid in the
+	    heirarchy.  This is in effect the global simulation timestep.
+	  <DT><b>level_timestep</b>
+	  <DD>The integer timestep for the grid with respect to the
+	    evolution on its particular level.
+	  <DT><b>persistence</b>
+	  <DD>The number of timesteps the grid persists on this
+	    particular level.  In terms of the other parameters it is
+	    the number of <i>timestep</i>s per <i>level_timestep</i>.
+	  <DT><b>spatial_refinement</b>
+	  <DD>The refinement in each cartesian direction.  This is a
+	    divisor which defines the refinement with respect to the
+	    toplevel (0-th level) grid.  So if the toplevel has a real
+	    delta of 1.0, then if a grid on a different level has a spatial refinement of 2,
+	    then the delta for the grid on that level is 0.5.
+	  <DT><b>time_refinement</b>
+	  <DD>The refinement for the timestep with respect to the
+	    toplevel (0-th level) grid stepsize.  So if the toplevel has a real
+	    timestep size of 1.0, then if a higher level grid has a time refinement of 2,
+	    then the timestep for the grid on that level is 0.5.
+	  <DT><b>grid_placement_refinement</b>
+	  <DD>This was created independently from the spatial_refinement
+	    for people who need to place staggered grids.  If you don't
+	    need staggered grids, then don't set this parameter (by
+	    default it is set equal to the spatial_refinement).
+	  <DT><b>iorigin</b>
+	  <DD>This is the integer origin of the grid placed in the
+	    coordinates of the spatial_refinement defined above.
+	</DL>
+    </dl>
+    <font face="arial,helvetica" color="#555588"><h2>The API</h2></font>
+    <UL>
+      <LI><a href="#CPP">C++ Interface</a>
+      <LI><a href="#C">C Interface</a>
+      <LI><a href="#F77">F77/F90 Interface</a>
+    </UL>
+    <hr>
+    <u><h2><a name="CPP">C++ Interface</a></h2></u>
+    <DL>
+      <DT><font color="#888888"><b>Constructors/Destructors</b></font>
+      <DD><DL>
+	  <DT><b>AMRwriter::AMRwriter(IObase
+		&filehandle)</b> <i>constructor</i>
+	  <DD>The <i>filehandle</i> is an already
+	    <a href="UsingC++.html#Opening">open IEEEIO or HDFIO
+	    file</a>.  This initializes the writer and attaches it to that
+	    datafile.
+	  <DT><b>AMRwriter::~AMRwriter()</b> <i>destructor</i>
+	  <DD>This flushes all of the necessary file buffers.
+	    The filehandle that the writer was bound to must be
+	    closed separately though.
+	</DL>
+      <DT><font color="#888888"><b>Initialization</b></font>
+      <DT><DL>
+      <DT><b>AMRwriter::setType(IObase::DataType datatype)</b>
+      <DD>Sets the <a href="DataTypes.html">datatype</a> 
+	for datasets written to the file.
+	The default is Float32 if you don't set this.
+      <DT><b>AMRwriter::setTopLevelParameters(int rank, double *origin,
+	  double *delta,double timestep)</b>
+      <DD>This sets number of dimentions (rank) for the dataset as
+	well as the floating-point coordinates and timestep for
+	the toplevel (level-0) grid.  From this information the
+	floating point parameters for all other grids can be
+	automatically generated from the stored integer coordinate
+	information.
+      <DT><b>AMRwriter::setRefinement(int maxdepth,
+	    int interlevel_timerefinement, int
+	    *interlevel_spatialrefinement,
+	    int *initial_gridplacementrefinement {default=None})</b>
+      <DD>This sets the integer factors of refinement recursively
+	for all levels down to a depth of <i>maxdepth.</i>  The
+	<i>interlevel</i> refinements are the integer factor of
+	refinement between levels.  This is always &gt 1.  <br>
+	The <i>initial_gridplacementrefinement</i> is only required if you need to
+	position the grids at a higher level of refinement than the
+	spatial refinement (eg. if you need to stagger the grids).  If
+	you do not specify this parameter, then it will assume the
+	gridplacement refinement is identical to the 
+	spatial refinement for each level.  The 
+	<i>initial_gridplacementrefinement</i>
+	specified here is the initial value of the refinement at the
+	toplevel.  The refinement increased proportionally to the
+	spatial refinement.  So refinements are computed as
+    <h4>spatialrefinement @ Level =
+      level^interlevel_refinement_ratio</h4>
+    <h4>gridplacementrefinement @ Level =
+      initial_gridplacement_refinement * 
+     interlevel_spatialrefinement^Level</h4><p>
+      <DT><b>AMRwriter::setLevelRefinement(int level,int
+	    timerefinement, int *spatialrefinement, int
+	    *gridplacementrefinement)</b>
+	<DD>This sets the integer factors of refinement for a given
+	  level with respect to the toplevel (0th level).  Normally
+	  you would use the <b>setRefinement()</b> method to set this
+	  for all levels in one step.  You only need to use
+	  <b>setLevelRefinement()</b> if each level has a different
+	  refinement criteria.<br>  From this,
+	  and the Toplevel floating point information, floating point
+	  grid-placement information can be computed automatically.
+	  If gridplacementrefinement is left NULL, then it is assumed
+	  that it is identical to the spatialrefinement.
+	  Storing this information as integers reduces the chance of
+	  problems caused by roundoff error.  Perhaps an "epsilon"
+	  should be stored to specify a tolerance for the roundoff.
+	</DL>
+	  <DT><font color="#888888"><b>Writing Data/Stepping</b></font>
+	    <DD><DL>
+		<DT><b>AMRwriter::setLevel(int *dims)</b>
+		<DD>This sets the current level.  Subsequent
+		  <code>write()</code> operations will assume this
+		  level for purposes of computing refinement and
+		  setting grid attibutes.
+		<DT><b>AMRwriter::setTime(int time)</b>
+		<DD>This sets the integer timestep for the data.  This
+		  is normally with respect to the finest level of
+		  refinement.  However, if you are only writing the
+		  hierarchy when the toplevel timestep is changed,
+		  then this can be with respect to the toplevel
+		  timestep.
+		<DT><b>AMRwriter::incrementTime()</b>
+		<DD>This can be used in lieu of
+		  <code>setTime()</code> if you don't have a global
+		  time counter availible to you in the IO routines.
+		  The timestep is maintained internally by the class
+		  and incremented whenever you call this
+		  incrementTime() method.
+		<DT><b>AMRwriter::write(int *origin,int *dims,void *data)</b>
+		<DD>Write the data for a grid to the file.  The origin
+		  is the integer origin using coordinates which are in
+		  terms of the <i>gridplacement refinement</i>
+		  for the current level.
+	      </DL>
+	    </DL>
+    <hr>
+    <h2><u><a name="C">C Interface</a></u></h2>
+    <DL>
+      <DT><font color="#888888"><b>Opening/Closing</b></font>
+      <DD><DL>
+	  <DT><b>AMRFile AMRbeginFile(IOFile filehandle)</b>
+	  <DD>The <i>filehandle</i> is an already
+	    <a href="UsingC.html#Opening">open IEEEIO or HDFIO
+	    file</a>.  This initializes the reader and attaches it to that
+	  datafile. This also creates a WRFile pointer for use by the
+	  AMRfile API.
+	<DT><b>AMRendFile(AMRFile filehandle)</b>
+	<DD>This flushes all of the necessary file buffer and
+	  deallocates the AMRFile pointer.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	</DL>
+      <DT><font color="#888888"><b>Initialization</b></font>
+      <DD><DL>
+      <DT><b>AMRsetType(AMRFile wrfile,int datatype)</b>
+	<DD>Sets the <a href="DataTypes.html">datatype</a>
+	    for datasets written to the file.
+	  The default is Float32 if you don't set this.
+	<DT><b>AMRsetToplevelParameters(AMRFile afile, int rank, double *origin,
+	    double *delta,double timestep)</b>
+	<DD>This sets the floating-point coordinates and timestep for
+	  the toplevel (level-0) grid. The <i>rank</i> is the number of
+	  dimensions for the dataset and is set for all subgrids of this
+	  dataset. From this information the
+	  floating point parameters for all other grids can be
+	  automatically generated from the stored integer coordinate
+	  information.
+	<DT><b>AMRsetRefinement(AMRFile file,int maxdepth,
+	      int interlevel_timerefinement, int
+	      *interlevel_spatialrefinement,
+	      int *initial_gridplacementrefinement)</b>
+	<DD>This sets the integer factors of refinement recursively
+	  for all levels down to a depth of <i>maxdepth.</i>  The
+	  <i>interlevel</i> refinements are the integer factor of
+	  refinement between levels.  This is always &gt 1.  <br>
+	  The <i>initial_gridplacementrefinement</i> is only required if you need to
+	  position the grids at a higher level of refinement than the
+	  spatial refinement (eg. if you need to stagger the grids).  If
+	  you specify this parameter as NULL, then it will assume the
+	  gridplacement refinement is identical to the 
+	  spatial refinement for each level.  The 
+	  <i>initial_gridplacementrefinement</i>
+	  specified here is the initial value of the refinement at the
+	  toplevel.  The refinement increased proportionally to the
+	  spatial refinement.  So refinements are computed as
+	  <h4>spatial_refinement @ Level =
+	    level^interlevelrefinement_ratio</h4>
+	  <h4>gridplacement_refinement @ Level =
+	    initial_gridplacement_refinement * 
+	    interlevel_spatial_refinement^Level</h4><p>	
+	<DT><b>AMRsetLevelRefinement(AMRFile afile,int level,int
+	    timerefinement, int *spatialrefinement, int
+	    *gridplacementrefinement)</b>
+	<DD>This sets the integer factors of refinement for a given
+	  level with respect to the toplevel (0th level).  Normally
+	  you would use the <b>AMRsetRefinement()</b> method to set this
+	  for all levels in one step.  You only need to use
+	  <b>setLevelRefinement()</b> if each level has a different
+	  refinement criteria.<br>  From this,
+	  and the Toplevel floating point information, floating point
+	  grid-placement information can be computed automatically.
+	  If gridplacementrefinement is left NULL, then it is assumed
+	  that it is identical to the spatialrefinement.
+	  Storing this information as integers reduces the chance of
+	  problems caused by roundoff error.  Perhaps an "epsilon"
+	  should be stored to specify a tolerance for the roundoff.
+      </DL>
+      <DT><font color="#888888"><b>Writing Data/Stepping</b></font>
+      <DD><DL>
+	  <DT><b>AMRsetLevel(AMRFile file,int level)</b>
+	  <DD>This sets the current level.  Subsequent
+	    <code>AMRwrite()</code> operations will assume this
+	    level for purposes of computing refinement and
+	    setting grid attibutes.
+	  <DT><b>AMRsetTime(AMRFile file,int time)</b>
+	  <DD>This sets the integer timestep for the data.  This
+	    is normally with respect to the finest level of
+	    refinement.  However, if you are only writing the
+	    hierarchy when the toplevel timestep is changed,
+	    then this can be with respect to the toplevel
+	    timestep.
+	  <DT><b>AMRincrementTime(AMRFile file)</b>
+	  <DD>This can be used in lieu of
+	    <code>AMRsetTime()</code> if you don't have a global
+	    time counter availible to you in the IO routines.
+	    The timestep is maintained internally by the class
+	    and incremented whenever you call this
+	    AMRincrementTime() method.
+	  <DT><b>AMRwrite(AMRFile file,int *origin,int *dims,void *data)</b>
+	  <DD>Write the data for a grid to the file.  The origin
+	    is the integer origin using coordinates which are in
+	    terms of the <i>gridplacement refinement</i>
+	    for the current level.  The <i>dims</i> are the
+	    actual dimensions of this grid of data you are writing.
+	</DL>
+    </DL>
+    <hr>    
+    <h2><u><a name="F77">F77/F90 Interface</a></u></h2>
+    <DL>
+      <DT><font color="#888888"><b>Opening/Closing</b></font>
+      <DD><DL>
+	  <DT><b>INTEGER*8 amr_begin(INTEGER*8 filehandle)</b>
+	  <DD>The <i>filehandle</i> is an already 
+	    <a href="UsingF77.html#Opening">open IEEEIO or HDFIO
+	    file</a>.  This initializes the reader and attaches it to that
+	  datafile. This also creates an INTEGER*8 pointer for use by the
+	  this API.
+	<DT><b>amr_end(INTEGER*8 filehandle)</b>
+	<DD>This flushes all of the necessary file buffer and
+	  deallocates the INTEGER*8 pointer.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	</DL>
+      <DT><font color="#888888"><b>Initialization</b></font>
+      <DD><DL>
+      <DT><b>amr_settype(INTEGER*8 wrfile, INTEGER datatype)</b>
+	<DD>Sets the <a href="DataTypes.html">datatype</a> 
+	    for datasets written to the file.
+	  The default is Float32 if you don't set this.
+	<DT><b>amr_setparams(INTEGER*8 afile, INTEGER rank, REAL*8 origin(<i>rank</i>),
+	    REAL*8 delta(<i>rank</i>),REAL*8 timestep)</b>
+	<DD>This sets the floating-point coordinates and timestep for
+	  the toplevel (level-0) grid. The <i>rank</i> is the number of
+	  dimensions for the dataset and is set for all subgrids of this
+	  dataset. From this information the
+	  floating point parameters for all other grids can be
+	  automatically generated from the stored integer coordinate
+	  information.
+	<DT><b>amr_setref(INTEGER*8 file, INTEGER maxdepth,
+	      INTEGER interlevel_timerefinement, INTEGER
+	      interlevel_spatialrefinement(),
+	      INTEGER initial_gridplacementrefinement())</b>
+	<DD>Set refinement for all grids.
+	    This sets the integer factors of refinement recursively
+	  for all levels down to a depth of <i>maxdepth.</i>  The
+	  <i>interlevel</i> refinements are the integer factor of
+	  refinement between levels.  This is always &gt 1.  <br>
+	  The <i>initial_gridplacementrefinement</i> is only required if you need to
+	  position the grids at a higher level of refinement than the
+	  spatial refinement (eg. if you need to stagger the grids).  If
+	  you specify this parameter as NULL, then it will assume the
+	  gridplacement refinement is identical to the 
+	  spatial refinement for each level.  The 
+	  <i>initial_gridplacementrefinement</i>
+	  specified here is the initial value of the refinement at the
+	  toplevel.  The refinement increased proportionally to the
+	  spatial refinement.  So refinements are computed as
+	  <h4>spatialrefinement @ Level =
+	    level^<i>interlevelrefinement_ratio</i></h4>
+	  <h4>gridplacementrefinement @ Level =
+	    <i>initial_gridplacementrefinement</i> * 
+	    <i>interlevelspatialrefinement</i>^Level</h4><p>	
+	<DT><b>amr_setlref(INTEGER*8 afile, INTEGER level, INTEGER
+	    timerefinement, INTEGER spatialrefinement(), INTEGER
+	    gridplacementrefinement())</b>
+	<DD>LevelRefinement (refinement per level).
+	  This sets the integer factors of refinement for a given
+	  level with respect to the toplevel (0th level).  Normally
+	  you would use the <b>amr_setRefinement()</b> method to set this
+	  for all levels in one step.  You only need to use
+	  <b>amr_setlref()</b> if each level has a different
+	  refinement criteria.<br>  From this,
+	  and the Toplevel floating point information, floating point
+	  grid-placement information can be computed automatically.
+	  If gridplacementrefinement is left NULL, then it is assumed
+	  that it is identical to the spatialrefinement.
+	  Storing this information as integers reduces the chance of
+	  problems caused by roundoff error.  Perhaps an "epsilon"
+	  should be stored to specify a tolerance for the roundoff.
+      </DL>
+      <DT><font color="#888888"><b>Writing Data/Stepping</b></font>
+      <DD><DL>
+	  <DT><b>amr_setlevel(INTEGER*8 file, INTEGER level)</b>
+	  <DD>This sets the current level.  Subsequent
+	    <code>write()</code> operations will assume this
+	    level for purposes of computing refinement and
+	    setting grid attibutes.
+	  <DT><b>amr_settime(INTEGER*8 file,INTEGER time)</b>
+	  <DD>This sets the integer timestep for the data.  This
+	    is normally with respect to the finest level of
+	    refinement.  However, if you are only writing the
+	    hierarchy when the toplevel timestep is changed,
+	    then this can be with respect to the toplevel
+	    timestep.
+	  <DT><b>amr_inctime(INTEGER*8 file)</b>
+	  <DD>This can be used in lieu of
+	    <code>setTime()</code> if you don't have a global
+	    time counter availible to you in the IO routines.
+	    The timestep is maintained internally by the class
+	    and incremented whenever you call this
+	    incrementTime() method.
+	  <DT><b>amr_write(INTEGER*8 file, INTEGER origin(), INTEGER
+		    dims(), <i>anytype</i> data())</b>
+	  <DD>Write the data for a grid to the file.  The origin
+	    is the integer origin using coordinates which are in
+	    terms of the <i>gridplacement refinement</i>
+	    for the current level.  The <i>dims</i> are the
+	    actual dimensions of this grid of data you are writing.
+	</DL>
+    </DL>
+    <hr>    
+    <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+    <!-- Created: Wed May  7 13:32:41 MDT 1997 -->
+    <!-- hhmts start -->
+Last modified: Thu Feb  4 15:18:25 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/AmrGrid.html b/doc/html/AmrGrid.html
new file mode 100644
index 0000000..f0b5a82
--- /dev/null
+++ b/doc/html/AmrGrid.html
@@ -0,0 +1,164 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>AMR Grid Data Structure</title>
+  </head>
+
+  <body>
+ 
+    <body bgcolor="#F0F0F0">
+    <font face="arial,helvetica"><h1>AMR Grid Datastructure</h1></font>
+      
+      Common to all of the AMR readers is an <b>AmrGrid</b>
+      informational datastructure.  This datastructure is <i>not</i>
+      necessary for the <a href="AMRwriter.html">AMRwriter</a>.  
+      This structure stores all of the
+      AMR parameters related to the grid that enable you to determine
+      where it should fit into the AMR hierarchy, the type of data
+      that it stores and the rank, dimensions, and physical size of
+      the grid.  It also has a pointer which can be used optionally 
+      to store the grid data.<p>
+
+	The structure has both a C and a C++ representation.  The only 
+	difference between the two is that the C structure represents
+	the datatype as an integer and the C++ version represents the
+	datatype as an enum.  Since the C++ struct is inherited
+	directly from the C version, the two interoperate
+	seamlessly.<p>
+<font face="arial,helvetica" color="#555588">
+	  <h2>Datastructure Specification</h2>
+	</font>
+	
+<table border=1><tr>
+<td>
+      	<font face="arial,helvetica" color="#885555"><b>C Datastructure</b></font>
+</td>
+<td>
+	<font face="arial,helvetica" color="#885555"><b>C++ Datastructure</b></font>
+</td>
+</tr>
+<tr><td>
+<pre>
+typedef struct AmrGrid {          
+  int level;
+  int maxlevel;
+  int maxtime;
+  int timestep;
+  int persistence; 
+  int rank;
+  int dims[3];
+  double delta[3];
+  double origin[3];
+  int timerefinement;
+  int nbytes;
+  int dataveclen;
+  int datatype;
+  void *data;
+} AmrGrid;
+</pre>
+</td><td>
+      <pre>
+struct AmrGrid {
+  // Members inherited from C AmrGrid 
+  int level;
+  int maxlevel;
+  int maxtime;
+  int timestep;
+  int persistence; 
+  int rank;
+  int dims[3];
+  double delta[3];
+  double origin[3];
+  int timerefinement;
+  int nbytes;
+  int dataveclen;
+  void *data;
+  // Members specific to C++ AmrGrid  
+  IObase::DataType datatype;
+};
+</pre></td></tr></table>
+
+	<font face="arial,helvetica" color="#555588">
+	  <h2>Datastructure Member Descriptions</h2>
+	</font>
+<DL>
+<DT><i>int</i> <b>level</b>
+<DD>The level in the AMR hierarchy. Level 0 is the Top (least refined)
+	  level.
+<DT><i>int</i> <b>maxlevel</b>
+<DD>The maximum number of levels in the AMR hierarchy for all
+	  timesteps stored in this file.  Levels are numbered from 0
+	  to maxlevel-1.
+<DT><i>int</i> <b>maxtime</b>
+<DD>Maximum timestep in the datafile.  This parameter is optional
+	  <i>(and generally unused)</i> and will be removed from 
+	  future releases.
+<DT><i>int</i> <b>timestep</b>
+<DD>This is the current integer timestep with respect to the finest
+	  granularity timestep that can occur in the file.  It is not
+	  necessarily uniform in time.  It simply delineates the order 
+	  in which things change in the file.  It is a fundamental
+	  parameter written by the <a href="AMRwriter.html">AMRwriter</a>.
+<DT><i>int</i> <b>persistence</b>
+<DD>This is the number of timesteps that the grid remains active from
+	  the timestep that it is created.  Like the <b>timestep</b>
+	  parameter, it can also be non-uniform.  It is an optional
+	  parameter that is often automatically computed by the
+	  AMRreader class from available data.
+<DT><i>int</i> <b>rank</b>
+<DD>The number of dimensions for the grid.  Currently you cannot mix
+	  grids of different dimensions together (ie. a 2D grid cannot 
+	  be embedded in a 3D grid), so if one grid is rank=3, then
+	  all of the grids in the file must have the same rank.
+<DT><i>int</i> <b>dims[3]</b>
+<DD>The dimensions of the grid (only the first <i>rank</i> values of
+	  this array will be filled).
+<DT><i>double</i> <b>delta[3]</b>
+<DD>The physical spacing between gridpoints.  This is actually
+	  redundant information since the same information can be
+	  inferred/computed from the <b>origin</b> and integer
+	  refinement information.  It is there for convenience though
+	  even though it is not as precise as the integer specification.
+<DT><i>double</i> <b>origin[3]</b>
+<DD>The physical origin (minimum extent in 3-space) of the grid.
+<DT><i>int</i> <b>timerefinement</b>
+<DD>The rate at which the grid steps at this level with respect to the 
+	  topgrid.  This is an optional parameter and will likely be
+	  dropped from future implementations of this system.
+<DT><i>int</i> <b>nbytes</b>
+<DD>Number of bytes of storage required for the grid data if it were loaded 
+	  into memory..  This is useful for memory allocation/management.
+<DT><i>int</i> <b>dataveclen</b>
+<DD>The number of elements-per-point in the data.  For instance a
+	  3D vector velocity field would have a dataveclen=3 for the i,j,k
+	  direction of the vector components.  dataveclen=1 for all
+	  scalar values like density and temperature.
+	  Currently this is not
+	  used, but will be in future implementations of the readers.
+<DT><i>int/IObase::DataType</i> <b>datatype</b>
+<DD>The type of the data as it is stored on disk.  This is represented 
+	  as an <i>integer</i> for C and as an <i>enum</i> of type
+	  <i>IObase::DataType</i> for C++.  The definitions for the
+	  <a href="DataTypes.html">datatypes are defined
+	    by the FlexIO libraries</a>.
+	  Integer datatypes are implemented in <a href="src/IO.h">IO.h</a>
+	  and the C++ <i>IObase::DataType</i> is implemented in 
+	  <a href="src/IO.hh">IO.hh</a>.
+ <DT><i>void *</i><b>data</b>
+	<DD>Pointer to memory array storing the data.  This is NULL
+	  if the data has not been loaded into memory.  So you can use 
+	  this datastructure just to aquire information about the
+	  grids and then load the data only when it is needed.
+</DL>
+
+	
+	
+
+    <hr>
+    <address><a href="mailto:jshalf@ncsa.uiuc.edu"></a></address>
+<!-- Created: Thu Jan 28 12:40:39 CST 1999 -->
+<!-- hhmts start -->
+Last modified: Thu Jan 28 17:14:34 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/Aquiring.html b/doc/html/Aquiring.html
new file mode 100644
index 0000000..2d17f0d
--- /dev/null
+++ b/doc/html/Aquiring.html
@@ -0,0 +1,102 @@
+<html>  
+  <head>
+    <title>Aquiring IEEEIO</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+      <h1>Aquiring IEEEIO</h1>
+      
+      IEEEIO is currently availible directly from this server.
+      <UL>
+	<LI><a href="src">The source directory</a>
+	<LI><a href="Binaries">Precompiled binaries</a>
+ <!-- <LI><a
+	href="ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar">gzip-1.2.4.tar  (<i>if you don't have gzip</i>)</a> -->
+	<LI><a href="http://infinite-entropy.ncsa.uiuc.edu/IEEEIO/src/ieeeio.tar.Z">ieeeio.tar.Z</a>
+	<LI><a href="http://infinite-entropy.ncsa.uiuc.edu/IEEEIO/src/ieeeio.tar.gz">ieeeio.tar.gz</a>
+      </UL>
+      <hr>
+
+<a name="binaries"><h1>Precompiled Binaries</h1></a>
+Precompiled binaries of IEEEIO are availible for the following architectures.
+The versions of these binaries labeled <b>+hdf</b> also include the full 
+<a href="http://hdf.ncsa.uiuc.edu/doc.html">
+HDF 4.1r1 library</a> binaries for convenience.<p>
+    <UL>
+	<LI><b>HP/UX 10.20 binaries</b><br>
+<!--<a href="Binaries/ieeeio+hdf.hpux_10.20.tar.Z">ieeeio+hdf.hpux_10.20.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.hpux_10.20.tar.gz">ieeeio+hdf.hpux_10.20.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.hpux_10.20.tar.Z">ieeeio.hpux_10.20.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio.hpux_10.20.tar.gz">ieeeio.hpux_10.20.tar.gz</a><p>
+
+	<LI><b>Irix 5.2/5.3 32-bit binaries</b><br>
+<!--<a href="Binaries/ieeeio+hdf.irix_5.3.tar.Z">ieeeio+hdf.irix_5.3.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.irix_5.3.tar.gz">ieeeio+hdf.irix_5.3.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.irix_5.3.tar.Z">ieeeio.irix_5.3.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio.irix_5.3.tar.gz">ieeeio.irix_5.3.tar.gz</a><p>
+
+	<LI><b>Irix 6.2 64-bit binaries</b> (<i>for Impacts, and Power Challenges</i>)<br>
+<!--<a href="Binaries/ieeeio+hdf.irix_6.2.tar.Z">ieeeio+hdf.irix_6.2.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.irix_6.2.tar.gz">ieeeio+hdf.irix_6.2.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.irix_6.2.tar.Z">ieeeio.irix_6.2.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio.irix_6.2.tar.gz">ieeeio.irix_6.2.tar.gz</a><p>
+	<LI><b>Irix 6.2 -n32 binaries</b> (<i>For r5k Indy's</i>)<br>
+<!--<a href="Binaries/ieeeio+hdf.irixn32_6.2.tar.Z">ieeeio+hdf.irixn32_6.2.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.irixn32_6.2.tar.gz">ieeeio+hdf.irixn32_6.2.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.irixn32_6.2.tar.Z">ieeeio.irixn32_6.2.tar.Z</a><br>-->
+	<a href="Binaries/ieeeio.irixn32_6.2.tar.gz">ieeeio.irixn32_6.2.tar.gz</a><p>
+	<LI><b>Irix 6.4 64-bit binaries</b> (<i>for Origin 2000 and Octane</i>)</a><br>
+<!--<a href="Binaries/ieeeio+hdf.irix_6.4.tar.Z">ieeeio+hdf.irix_6.4.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.irix_6.4.tar.gz">ieeeio+hdf.irix_6.4.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.irix_6.4.tar.Z">ieeeio.irix_6.4.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio.irix_6.4.tar.gz">ieeeio.irix_6.4.tar.gz</a><p>
+	<LI><b>Irix 6.4 -n32 binaries</b></a><br>
+<!--<a href="Binaries/ieeeio+hdf.irixn32_6.4.tar.Z">ieeeio+hdf.irixn32_6.4.tar.Z</a><br> -->
+	<a href="Binaries/ieeeio+hdf.irixn32_6.4.tar.gz">ieeeio+hdf.irixn32_6.4.tar.gz</a><br>
+<!--<a href="Binaries/ieeeio.irixn32_6.4.tar.Z">ieeeio.irixn32_6.4.tar.Z</a><br>-->
+	<a href="Binaries/ieeeio.irixn32_6.4.tar.gz">ieeeio.irixn32_6.4.tar.gz</a><p>
+    </UL>
+    <hr>
+<a name="binaries"><h1>Compiling IEEEIO</h1></a>
+To compile IEEEIO you need the following
+<UL>
+<LI>GNU make 
+<a href="ftp://prep.ai.mit.edu/pub/gnu/make-2.75.tar.gz">(make-2.75.tar.gz)</a>
+<a href="http://www.fsf.org"><img border=0 src="Images/info.s.gif"></a>
+<LI>A C++ compiler (CC or 
+<a href="ftp://prep.ai.mit.edu/pub/gnu/gcc-2.7.2.2.tar.gz">g++</a>)
+<a href="http://www.fsf.org"><img border=0 src="Images/info.s.gif"></a>
+<LI>If you need to get any of the gnu utilities, you may also need 
+	  <a href="ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar">gzip</a>.
+	  <a href="http://www.fsf.org"><img border=0 src="Images/info.s.gif"></a>
+</UL>
+
+The makefile sets up make parameters based on the identification of
+the machine using the 'uname' command.  It currently recognizes the
+following architectures
+<UL>
+	<LI>Cray T3E
+	<LI>DEC Alpha/OSF
+	<LI>HP/Convex
+	<LI>Intel/Windows Cygwin
+	<LI>Macintosh MachTen
+	<LI>SGI IRIX 5.x
+	<LI>SGI IRIX64 6.x
+	<LI>Sun Solaris 2.x
+</UL>
+
+The <a href="src/Makefile"><b>Makefile</b></a> is very small so you should take a look a it with a text editor to make certain that all of the parameters are correct for your machine.  Most notably, if you want to be able to use the ieeeio libraries with HDF then you need to make certain that the correct paths to your HDF installation have been set.<p>
+
+Simply type <b>gmake</b> to build the default ieeeio library and utilities.  Type <b>gmake libhdfio.a</b> to build the HDF interoperability libraries and related utilities.<p>  
+
+To test the operation of of the library type <b>gmake data3d.raw</b>.  This will build a test program that will write an IEEEIO file and then reopen it for reading.  If this program runs successfully, then the library has been built successfully.<p>
+
+
+
+<hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Fri May 29 12:33:03 CDT 1998
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/DataTypes.html b/doc/html/DataTypes.html
new file mode 100644
index 0000000..80423ae
--- /dev/null
+++ b/doc/html/DataTypes.html
@@ -0,0 +1,188 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>DataTypes</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+  <body>
+    <font face="arial,helvetica" color="#555588"><h1>DataTypes</h1></font>
+    HDF and IEEEIO must be able to store any of the basic datatypes
+    available to a given computer architecture (various sized integers 
+    and floating point numbers).  In Fortran the datatype is
+    identified by an integer.  In C we use <b>#defines</b>.  In C++ we
+    use <b>enums</b>.  There are also simple built-in utility operations
+      available which allow computation of data space used by these
+      various datatypes (<i>
+      <a href="#sizeof">sizeOf()</a>, 
+      <a href="#nelements">nElements()</a>, 
+      <a href="#nbytes">nBytes()</a>
+      </i>)<p>
+
+Here is how the types are related.<p>
+
+<table border=1>
+<tr>
+<td> <font face="arial,helvetica" color="#885533"><b>Datatype</b></font></td>
+<td> <font face="arial,helvetica" color="#885533"><b>Num Bytes</b></font></td>
+<td> <font face="arial,helvetica" color="#885533"><b>C++ TypeID</b></font></td>
+<td> <font face="arial,helvetica" color="#885533"><b>C TypeID</b></font></td>
+<td> <font face="arial,helvetica" color="#885533"><b>Fortran TypeID</b></font></td>
+</tr>
+
+<tr>
+<td>byte binary data <i>(not to be confused with text/strings)</i>
+<td>1
+<td>Byte,Int8
+<td>BYTE,INT8
+<td>0
+<tr>
+
+<td>short (16bit) integer
+<td>2
+<td>Int16
+<td>INT16
+<td>1
+<tr>
+<td>32bit integer
+<td>4
+<td>Int32
+<td>INT32
+<td>2
+<tr>
+<td>64bit integer
+<td>8
+<td>Int64
+<td>INT64
+<td>3
+<tr>
+<td>single precision floating point
+<td>4
+<td>Float32
+<td>FLOAT32
+<td>4
+<tr>
+<td>double precision floating point
+<td>8
+<td>Float64
+<td>FLOAT64
+<td>5
+<tr>
+<td>unsigned byte
+<td>1
+<td>uChar,uInt8
+<td>UCHAR,UINT8
+<td>6
+<tr>
+<td>unsigned short (16 bit) integer
+<td>2
+<td>uInt16
+<td>UINT16
+<td>7
+<tr>
+<td>unsigned 32bit integer
+<td>4
+<td>uInt32
+<td>UINT32
+<td>8
+<tr>
+<td>unsigned 64bit integer
+<td>8
+<td>uInt64
+<td>UINT64
+<td>9
+<tr>
+<td>special byte type for text data <i>(to differentiate it from binary byte data)</i>
+<td>1
+<td>Char,Char8,String
+<td>CHAR,CHAR8,STRING 
+<td>10
+<tr>
+<td>special type for unicode (16bit) text to differentiate from binary 
+																		  unsigned integer data
+<td>2
+<td>Unicode,Char16
+<td>UNICODE,CHAR16
+<td>11
+
+	</table><p>
+
+      <hr>
+      <font face="arial,helvetica" color="#555588"><h2><a name="utils">Utility Subroutines</a></h2></font>
+      Various utility subroutines can be used to use the type
+      information to compute data array sizes.
+      <a name="nbytes"><u><h3>Number of Bytes in a Dataset</h3></u></a>
+      <DL>
+	<DD>
+      <DL>
+	<DT><b>C++ Call Format</b>
+	<DD><code>int IObase::nBytes(IObase::DataType datatype,int rank,int *dims)</code>
+	<DT><b>C Call Format</b>
+	<DD><code>int IOnBytes(int datatype,int rank,int *dims)</code>
+	<DT><b>F77 Call Format</b>
+	<DD> <code>INTEGER IO_NBYTES(INTEGER datatype,INTEGER
+	    rank,INTEGER dims(*))</code></DL>
+      <hr>
+	  <DL>
+	    <DT><i>datatype</i>:
+	    <DD>The datatype for elements of the array
+	    <DT><i>rank</i>:
+	    <DD>The number of dimensions of the array
+	    <DT><i>dims</i>:
+	    <DD>A vector of the dimensions of the array
+	    <DT><font color="#885533"><b><i>returns</i></b></font>
+	    <DD>Returns the number of bytes required to store the array
+	  </DL>
+      <hr>
+      </DL>
+
+      <a name="nelements"><u><h3>Number of Elements in a Dataset</h3></u></a>
+       <DL>
+	<DD>
+	  <DL>
+	<DT><b>C++ Call Format</b>
+	<DD><code>int IObase::nElements(int rank,int *dims)</code>
+	<DT><b>C Call Format</b>
+	<DD><code>int IOnElements(int rank,int *dims)</code>
+	<DT><b>F77 Call Format</b>
+	<DD> <code>INTEGER IO_NELEMENTS(INTEGER rank,INTEGER dims(*))</code></DL>
+	  <hr>
+	  <DL>
+	    <DT><i>rank</i>:
+	    <DD>The number of dimensions of the array
+	    <DT><i>dims</i>:
+	    <DD>A vector of the dimensions of the array
+	    <DT><font color="#885533"><b><i>returns</i></b></font>
+	    <DD>Returns the number of elements required in the array
+	  </DL>
+      <hr>
+      </DL>
+
+      <a name="sizeof"><u><h3>Size of a DataType in Bytes</h3></u></a>
+       <DL>
+	<DD>
+	  <DL>
+	<DT><b>C++ Call Format</b>
+	<DD><code>int IObase::sizeOf(IObase::DataType datatype)</code>
+	<DT><b>C Call Format</b>
+	<DD><code>int IOsizeOf(int datatype)</code>
+	<DT><b>F77 Call Format</b>
+	<DD> <code>INTEGER IO_SIZEOF(INTEGER datatype)</code></DL>
+      <hr>
+	  <DL>
+	    <DT><i>datatype</i>:
+	    <DD>The datatype for elements of the array.
+	    <DT><font color="#885533"><b><i>returns</i></b></font>
+	    <DD>Returns the number of bytes used by an element of the
+	      specified datatype.
+	  </DL>
+      <hr>
+      </DL>
+
+      <hr>
+      <address><a href="mailto:jshalf@ariel.ncsa.uiuc.edu"></a></address>
+      <!-- Created: Thu Jan 28 16:35:13 CST 1999 -->
+      <!-- hhmts start -->
+Last modified: Wed Feb  3 22:02:45 CST 1999
+<!-- hhmts end -->
+    </body>
+</html>
diff --git a/doc/html/HighLev.html b/doc/html/HighLev.html
new file mode 100644
index 0000000..978563e
--- /dev/null
+++ b/doc/html/HighLev.html
@@ -0,0 +1,43 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>High Level IEEEIO Interfaces</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+      <h1>High Level IEEEIO Interfaces</h1>
+
+      These interfaces sit on top of the basic IO interfaces defined
+      in the IEEEIO/HDFIO document to describe specific types of data.
+      So the file format can be read using the low-level IEEEIO/HDF
+      interfaces without difficulty.  These interfaces simply codify
+      certain file attributes to describe particular types of
+      data.<p>
+
+      These are each separate APIs that take a pointer to the
+      IEEEIO or HDFIO interfaces in order to do their work.<p>
+	
+      <h1>Writers</h1>
+      <UL>
+	<LI><a href="Writer.html">Simple Unigrid Writer</a>
+	<LI><a href="UCDwriter.html">Unstructured Cell Data
+	    (Finite-Element) Writer</a>
+	<LI>Heirarchial Adaptive Mesh (AMR) Readers/Writers
+	<dl>
+	  <DD><a href="AmrGrid.html">AMR Grid Datastructures</a>
+	  <DD><a href="AMRwriter.html">AMR Writer</a>
+	  <DD><a href="AMRreaderBase.html">Simple AMR Reader (AmrGridReader)</a>
+	  <DD><a href="AMRfileReader.html">Fancy AMR Reader (AmrFileReader)</a>
+	  <DD><a href="AMRucdReader.html">AMR reader with
+	      automatic translation to Finite Element
+	      datastructures</a>
+	</dl>
+      </UL>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+<!-- Created: Wed May  7 12:28:58 MDT 1997 -->
+<!-- hhmts start -->
+Last modified: Thu Feb  4 20:35:57 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/IEEEIO.html b/doc/html/IEEEIO.html
new file mode 100644
index 0000000..43584a8
--- /dev/null
+++ b/doc/html/IEEEIO.html
@@ -0,0 +1,48 @@
+<html>  
+  <head>
+    <title>IEEEIO Info</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+    <img src="Images/ieeeiotitle.gif">
+      <hr>
+      <h1>Introduction</h1>
+      IEEEIO is a compact library for storing multidimensional
+      scientific data in a binary format that can be transported
+      between different computer systems.  It derives its name from the
+      fact that it depends on the 
+      <a href="http://standards.ieee.org/catalog/it.html#gen184">IEEE
+	754</a> 
+      standard representations
+      for  floating point numbers to achieve its portability.  It
+      provides  many of the capabilities of the 
+      <a href="http://hdf.ncsa.uiuc.edu">HDF-SDS</a> and NetCDF
+      file  formats however it is much smaller and simpler than
+      either.  In addition, it is <a href="Performance.html">
+	reasonably fast</a> when compared
+      to raw f77 unformatted IO.
+
+	The programming interface allows complete
+      interoperability  with the HDF and NetCDF formats if those
+      libraries  are linked in.  It is not intended to supercede these
+      formats.  It is designed to replace them only where the extra
+      functionality  and consequent size of these libraries is not
+      desired.<p>
+      <hr>
+      <h1>Information</h1>
+      <UL>
+	<LI><a href="why.html">Why IEEEIO</a>
+	<LI><a href="Performance.html">Performance</a>
+	<LI><a href="Aquiring.html">Aquiring the source code and compiling IEEEIO</a>
+	<LI><a href="Using.html">Using IEEEIO</a>
+	<LI><a href="Utilities.html">Utilities and Data Translators</a>
+	<LI><a href="VizReaders.html">Readers for Visualization Systems</a>
+	<LI><a href="HighLev.html">Higher level interfaces</a>
+      </UL>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Fri May 29 10:06:40 CDT 1998
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/IOspeed.cc b/doc/html/IOspeed.cc
new file mode 100644
index 0000000..ab72a2b
--- /dev/null
+++ b/doc/html/IOspeed.cc
@@ -0,0 +1,86 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/times.h>
+#include <time.h>
+#include "IO.hh"
+#include "IEEEIO.hh"
+#include "HDFIO.hh"
+extern "C" {
+void openf77_();
+void writef77_(double *data);
+void closef77_();
+}
+
+void main(){
+  double data[64*64*64];
+  int dims[3]={64,64,64};
+  int i,nds;
+  puts("--------------IEEE--------------");
+  for(i=0,nds=5;i<8;i++,nds+=5){
+    time_t stm,etm;
+    struct tms stms,etms;
+    time(&stm);
+    times(&stms);
+    IObase *file = new IEEEIO("speed.raw",IObase::Write);
+    fprintf(stderr,"Write %2u:",nds);
+    for(int n=0;n<nds;n++){
+      fprintf(stderr,"*");
+      file->write(IObase::Float64,3,dims,data);
+    }
+    delete file;
+    times(&etms);
+    time(&etm);
+    printf("\n\tRealtime=%d, UserTime=%d, SystemTime=%d, Combined=%u\n",
+	   etm-stm,
+	   etms.tms_utime-stms.tms_utime,
+	   etms.tms_stime-stms.tms_stime,
+	   etms.tms_utime-stms.tms_utime+etms.tms_stime-stms.tms_stime);
+  }
+
+  puts("--------------HDF---------------");
+  for(i=0,nds=5;i<8;i++,nds+=5){
+    time_t stm,etm;
+    struct tms stms,etms;
+    time(&stm);
+    times(&stms);
+    IObase *file = new HDFIO("speed.hdf",IObase::Write);
+    fprintf(stderr,"Write %2u:",nds);
+    for(int n=0;n<nds;n++){
+      fprintf(stderr,"*");
+      file->write(IObase::Float64,3,dims,data);
+    }
+    delete file;
+    times(&etms);
+    time(&etm);
+    printf("\n\tRealtime=%d, UserTime=%d, SystemTime=%d, Combined=%u\n",
+	   etm-stm,
+	   etms.tms_utime-stms.tms_utime,
+	   etms.tms_stime-stms.tms_stime,
+	   etms.tms_utime-stms.tms_utime+etms.tms_stime-stms.tms_stime);
+  }
+
+  puts("-------------F77 Unformatted---------------");
+  for(i=0,nds=5;i<8;i++,nds+=5){
+    time_t stm,etm;
+    struct tms stms,etms;
+    time(&stm);
+    times(&stms);
+    fprintf(stderr,"Write %2u:",nds);
+    openf77_();
+    // writef77_(dat,&nds);
+    for(int n=0;n<nds;n++){
+      fprintf(stderr,"*");
+      writef77_(data);
+    }
+    closef77_();
+    times(&etms);
+    time(&etm);
+    printf("\n\tRealtime=%d, UserTime=%d, SystemTime=%d, Combined=%u\n",
+           etm-stm,
+           etms.tms_utime-stms.tms_utime,
+           etms.tms_stime-stms.tms_stime,
+           etms.tms_utime-stms.tms_utime+etms.tms_stime-stms.tms_stime);
+  }
+}
+
diff --git a/doc/html/Images/FlexIO.gif b/doc/html/Images/FlexIO.gif
new file mode 100644
index 0000000..8b090da
--- /dev/null
+++ b/doc/html/Images/FlexIO.gif
diff --git a/doc/html/Images/ieeeiotitle.gif b/doc/html/Images/ieeeiotitle.gif
new file mode 100644
index 0000000..8504374
--- /dev/null
+++ b/doc/html/Images/ieeeiotitle.gif
diff --git a/doc/html/Images/info.gif b/doc/html/Images/info.gif
new file mode 100644
index 0000000..8c32e47
--- /dev/null
+++ b/doc/html/Images/info.gif
diff --git a/doc/html/Images/info.s.gif b/doc/html/Images/info.s.gif
new file mode 100644
index 0000000..b208506
--- /dev/null
+++ b/doc/html/Images/info.s.gif
diff --git a/doc/html/Performance.html b/doc/html/Performance.html
new file mode 100644
index 0000000..c5b0452
--- /dev/null
+++ b/doc/html/Performance.html
@@ -0,0 +1,423 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>IEEEIO Performance</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+      <h1>IEEEIO Performance Comparisons</h1>
+
+The performance of IEEEIO, HDF 4.1r1, and F77 unformatted IO are
+compared.  Each system is set up to write between 5 and 40 
+datasets.  Each dataset is 64^3 double precision floats.
+The <i>realtime</i> (wallclock time) 
+is measured in seconds using time() which is
+coarse, but good enough for this comparison.  The <i>system</i> and
+<i>user</i> times (CPU times) were measured using the times() 
+system call which reports in clock ticks.  The <i>combined</i>
+time is the sum of user and system times.
+The timing of each of the IO systems includes the opening and
+closing of the files so that buffer flushing and file indexing
+can be taken into account.  The program used to do the testing
+is <a href="IOspeed.cc">IOspeed.cc</a> and uses 
+<a href="writef77.f">writef77.f</a> to handle the F77 IO.
+
+Testing hasn't been done on too many architectures yet but as
+data is collected it will be posted here.
+    <ul>
+      <li><a href="#Octane">SGI Octane</a>
+      <li><a href="#Origin">SGI Origin 2000</a>
+      <li><a href="#SPP1200">Convex SPP-1200</a>
+      <li><a href="#SClass">Convex S-class</a>
+      <!-- <li><a href="#XClass">Convex X-class</a> -->
+      <li><a href="#Alpha2100">DEC AlphaServer 2100 4/275</a>
+      <li><a href="#Alpha600">DEC AlphaStation 600 5/266</a>
+    </ul>
+<hr>
+<a name="Octane"><h2>Octane Performance</h2></a>
+5 to 40 double precision float datasets with 64 x 64 x 64 elements
+were written to the scratch disk.
+(each <b>*</b> represents writing a single datasets)<p>
+
+The test was performed on Octane while
+the machine was unloaded.  The machine has one 195 MHz 
+R10000 processor, 512 Megs RAM.  A 2-disk fast-wide SCSI-3 
+RAID 0 array was used  as the data drive for the test.   
+This data is from a single run.
+More tests will be done to build an averaged score.<p>
+
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=0, UserTime=0, SystemTime=11, Combined=11
+Write 10:**********
+        Realtime=1, UserTime=2, SystemTime=22, Combined=24
+Write 15:***************
+        Realtime=3, UserTime=0, SystemTime=32, Combined=32
+Write 20:********************
+        Realtime=4, UserTime=0, SystemTime=43, Combined=43
+Write 25:*************************
+        Realtime=6, UserTime=1, SystemTime=54, Combined=55
+Write 30:******************************
+        Realtime=7, UserTime=0, SystemTime=64, Combined=64
+Write 35:***********************************
+        Realtime=8, UserTime=1, SystemTime=75, Combined=76
+Write 40:****************************************
+        Realtime=9, UserTime=1, SystemTime=86, Combined=87
+--------------HDF---------------
+Write  5:*****
+        Realtime=1, UserTime=30, SystemTime=25, Combined=55
+Write 10:**********
+        Realtime=2, UserTime=61, SystemTime=49, Combined=110
+Write 15:***************
+        Realtime=4, UserTime=91, SystemTime=75, Combined=166
+Write 20:********************
+        Realtime=16, UserTime=122, SystemTime=99, Combined=221
+Write 25:*************************
+        Realtime=8, UserTime=153, SystemTime=124, Combined=277
+Write 30:******************************
+        Realtime=9, UserTime=181, SystemTime=150, Combined=331
+Write 35:***********************************
+        Realtime=11, UserTime=213, SystemTime=175, Combined=388
+Write 40:****************************************
+        Realtime=13, UserTime=241, SystemTime=200, Combined=441
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=0, UserTime=1, SystemTime=11, Combined=12
+Write 10:**********
+        Realtime=1, UserTime=0, SystemTime=24, Combined=24
+Write 15:***************
+        Realtime=3, UserTime=0, SystemTime=36, Combined=36
+Write 20:********************
+        Realtime=14, UserTime=0, SystemTime=48, Combined=48
+Write 25:*************************
+        Realtime=5, UserTime=0, SystemTime=60, Combined=60
+Write 30:******************************
+        Realtime=7, UserTime=1, SystemTime=72, Combined=73
+Write 35:***********************************
+        Realtime=8, UserTime=0, SystemTime=84, Combined=84
+Write 40:****************************************
+        Realtime=10, UserTime=0, SystemTime=96, Combined=96
+</pre>
+<hr>
+<a name="Origin"><h2>Origin 2000</h2></a>
+5-40 64^3 double-precision float datasets were written 
+(each '*' represents
+writing a single datasets)<p>
+Test performed on the SGI Origin 2000 origin.aei-potsdam.mpg.de 
+while the machine was moderately loaded.  The machine has 32 195 MHz 
+R10000 processors, 8Gigabytes RAM.  A mulit-disk RAID 0 array was used 
+as the data drive for the test.   This is from a single run.
+More tests will be done to create an averaged score.<p>
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=0, UserTime=2, SystemTime=18, Combined=20
+Write 10:**********
+        Realtime=2, UserTime=0, SystemTime=26, Combined=26
+Write 15:***************
+        Realtime=1, UserTime=0, SystemTime=39, Combined=39
+Write 20:********************
+        Realtime=3, UserTime=1, SystemTime=53, Combined=54
+Write 25:*************************
+        Realtime=3, UserTime=0, SystemTime=65, Combined=65
+Write 30:******************************
+        Realtime=3, UserTime=1, SystemTime=76, Combined=77
+Write 35:***********************************
+        Realtime=6, UserTime=1, SystemTime=97, Combined=98
+Write 40:****************************************
+        Realtime=6, UserTime=1, SystemTime=107, Combined=108
+--------------HDF---------------
+Write  5:*****
+        Realtime=1, UserTime=44, SystemTime=33, Combined=77
+Write 10:**********
+        Realtime=3, UserTime=86, SystemTime=61, Combined=147
+Write 15:***************
+        Realtime=3, UserTime=129, SystemTime=85, Combined=214
+Write 20:********************
+        Realtime=7, UserTime=171, SystemTime=115, Combined=286
+Write 25:*************************
+        Realtime=6, UserTime=215, SystemTime=139, Combined=354
+Write 30:******************************
+        Realtime=8, UserTime=258, SystemTime=169, Combined=427
+Write 35:***********************************
+        Realtime=10, UserTime=300, SystemTime=200, Combined=500
+Write 40:****************************************
+        Realtime=12, UserTime=340, SystemTime=231, Combined=571
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=0, UserTime=0, SystemTime=20, Combined=20
+Write 10:**********
+        Realtime=2, UserTime=0, SystemTime=30, Combined=30
+Write 15:***************
+        Realtime=2, UserTime=0, SystemTime=45, Combined=45
+Write 20:********************
+        Realtime=1, UserTime=1, SystemTime=60, Combined=61
+Write 25:*************************
+        Realtime=5, UserTime=0, SystemTime=77, Combined=77
+Write 30:******************************
+        Realtime=4, UserTime=0, SystemTime=93, Combined=93
+Write 35:***********************************
+        Realtime=6, UserTime=1, SystemTime=108, Combined=109
+Write 40:****************************************
+        Realtime=5, UserTime=0, SystemTime=123, Combined=123
+</pre>
+<hr>
+<a name="SPP1200"><h2>HP/Convex SPP-1200</h2></a>
+5-40 64^3 double-precision float datasets were written
+(each '*' represents writing a single datasets)<p>
+Test performed on an HP/Convex SPP-1200 (lena.ncsa.uiuc.edu)
+while the machine was moderately loaded.  The machine has 64 120 MHz
+PA7200 processors, 8Gigabytes RAM.  A mulit-disk RAID 0 array was used
+as the data drive for the test.   This is from a single run.
+More tests will be done to create an averaged score.<p>
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=2, UserTime=0, SystemTime=1, Combined=1
+Write 10:**********
+        Realtime=1, UserTime=1, SystemTime=0, Combined=1
+Write 15:***************
+        Realtime=3, UserTime=0, SystemTime=0, Combined=0
+Write 20:********************
+        Realtime=4, UserTime=1, SystemTime=0, Combined=1
+Write 25:*************************
+        Realtime=4, UserTime=2, SystemTime=0, Combined=2
+Write 30:******************************
+        Realtime=6, UserTime=3, SystemTime=0, Combined=3
+Write 35:***********************************
+        Realtime=5, UserTime=2, SystemTime=0, Combined=2
+Write 40:****************************************
+        Realtime=7, UserTime=2, SystemTime=1, Combined=3
+--------------HDF---------------
+Write  5:*****
+        Realtime=3, UserTime=134, SystemTime=12, Combined=146
+Write 10:**********
+        Realtime=5, UserTime=254, SystemTime=7, Combined=261
+Write 15:***************
+        Realtime=8, UserTime=379, SystemTime=19, Combined=398
+Write 20:********************
+        Realtime=11, UserTime=524, SystemTime=19, Combined=543
+Write 25:*************************
+        Realtime=18, UserTime=688, SystemTime=24, Combined=712
+Write 30:******************************
+        Realtime=23, UserTime=801, SystemTime=22, Combined=823
+Write 35:***********************************
+        Realtime=24, UserTime=947, SystemTime=27, Combined=974
+Write 40:****************************************
+        Realtime=25, UserTime=1087, SystemTime=28, Combined=1115
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=1, UserTime=39, SystemTime=15, Combined=54
+Write 10:**********
+        Realtime=2, UserTime=91, SystemTime=1, Combined=92
+Write 15:***************
+        Realtime=4, UserTime=133, SystemTime=0, Combined=133
+Write 20:********************
+        Realtime=4, UserTime=169, SystemTime=1, Combined=170
+Write 25:*************************
+        Realtime=7, UserTime=211, SystemTime=2, Combined=213
+Write 30:******************************
+        Realtime=11, UserTime=275, SystemTime=0, Combined=275
+Write 35:***********************************
+        Realtime=10, UserTime=318, SystemTime=3, Combined=321
+Write 40:****************************************
+        Realtime=9, UserTime=348, SystemTime=6, Combined=354
+</pre>
+<hr>
+<a name="SClass"><h2>HP/Convex S-Class</h2></a>
+5-40 64^3 double-precision float datasets were written
+(each '*' represents
+writing a single datasets)<p>
+Test performed on an alpha-version of the HP/Convex S-Class 
+while the machine was moderately loaded.  The machine has 16 180 MHz
+PA8000 processors, 4Gigabytes RAM.  A mulit-disk RAID 0 array was used
+as the data drive for the test.   This is from a single run.
+More tests will be done to create an averaged score.<p>
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=7, UserTime=0, SystemTime=1, Combined=1
+Write 10:**********
+        Realtime=1, UserTime=0, SystemTime=0, Combined=0
+Write 15:***************
+        Realtime=1, UserTime=0, SystemTime=0, Combined=0
+Write 20:********************
+        Realtime=1, UserTime=0, SystemTime=1, Combined=1
+Write 25:*************************
+        Realtime=1, UserTime=1, SystemTime=0, Combined=1
+Write 30:******************************
+        Realtime=2, UserTime=1, SystemTime=0, Combined=1
+Write 35:***********************************
+        Realtime=2, UserTime=2, SystemTime=1, Combined=3
+Write 40:****************************************
+        Realtime=3, UserTime=3, SystemTime=1, Combined=4
+--------------HDF---------------
+Write  5:*****
+        Realtime=4, UserTime=52, SystemTime=4, Combined=56
+Write 10:**********
+        Realtime=3, UserTime=121, SystemTime=5, Combined=126
+Write 15:***************
+        Realtime=4, UserTime=159, SystemTime=8, Combined=167
+Write 20:********************
+        Realtime=7, UserTime=216, SystemTime=16, Combined=232
+Write 25:*************************
+        Realtime=7, UserTime=262, SystemTime=23, Combined=285
+Write 30:******************************
+        Realtime=11, UserTime=322, SystemTime=19, Combined=341
+Write 35:***********************************
+        Realtime=9, UserTime=361, SystemTime=33, Combined=394
+Write 40:****************************************
+        Realtime=13, UserTime=422, SystemTime=31, Combined=453
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=1, UserTime=27, SystemTime=8, Combined=35
+Write 10:**********
+        Realtime=2, UserTime=58, SystemTime=0, Combined=58
+Write 15:***************
+        Realtime=2, UserTime=90, SystemTime=0, Combined=90
+Write 20:********************
+        Realtime=2, UserTime=112, SystemTime=0, Combined=112
+Write 25:*************************
+        Realtime=3, UserTime=137, SystemTime=2, Combined=139
+Write 30:******************************
+        Realtime=3, UserTime=174, SystemTime=0, Combined=174
+Write 35:***********************************
+        Realtime=6, UserTime=203, SystemTime=0, Combined=203
+Write 40:****************************************
+        Realtime=4, UserTime=223, SystemTime=1, Combined=224
+</pre>
+<hr>
+<a name="Alpha2100"><h2>DEC AlphaServer 2100 4/275</h2></a>
+5-40 64^3 double-precision float datasets were written
+(each '*' represents
+writing a single datasets)<p>
+Test performed on a DEC AlphaServer 2100 4/275 
+while the machine was unloaded.  The machine has 1 275 MHz
+Alpha ev 4 processor, 32Megabytes RAM.  A single SCSI-2 disk was used
+as the data drive for the test.   This is from a single run.
+More tests will be done to create an averaged score.<p>
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=1, UserTime=1, SystemTime=29, Combined=30
+Write 10:**********
+        Realtime=8, UserTime=0, SystemTime=49, Combined=49
+Write 15:***************
+        Realtime=9, UserTime=0, SystemTime=75, Combined=75
+Write 20:********************
+        Realtime=14, UserTime=0, SystemTime=101, Combined=101
+Write 25:*************************
+        Realtime=16, UserTime=1, SystemTime=126, Combined=127
+Write 30:******************************
+        Realtime=18, UserTime=0, SystemTime=152, Combined=152
+Write 35:***********************************
+        Realtime=23, UserTime=1, SystemTime=178, Combined=179
+Write 40:****************************************
+        Realtime=26, UserTime=1, SystemTime=204, Combined=205
+--------------HDF---------------
+Write  5:*****
+        Realtime=8, UserTime=106, SystemTime=47, Combined=153
+Write 10:**********
+        Realtime=17, UserTime=214, SystemTime=89, Combined=303
+Write 15:***************
+        Realtime=25, UserTime=317, SystemTime=138, Combined=455
+Write 20:********************
+        Realtime=31, UserTime=425, SystemTime=185, Combined=610
+Write 25:*************************
+        Realtime=34, UserTime=533, SystemTime=228, Combined=761
+Write 30:******************************
+        Realtime=40, UserTime=640, SystemTime=276, Combined=916
+Write 35:***********************************
+        Realtime=49, UserTime=743, SystemTime=326, Combined=1069
+Write 40:****************************************
+        Realtime=55, UserTime=852, SystemTime=369, Combined=1221
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=3, UserTime=11, SystemTime=32, Combined=43
+Write 10:**********
+        Realtime=6, UserTime=20, SystemTime=64, Combined=84
+Write 15:***************
+        Realtime=10, UserTime=28, SystemTime=85, Combined=113
+Write 20:********************
+        Realtime=12, UserTime=40, SystemTime=117, Combined=157
+Write 25:*************************
+        Realtime=18, UserTime=52, SystemTime=139, Combined=191
+Write 30:******************************
+        Realtime=18, UserTime=64, SystemTime=170, Combined=234
+Write 35:***********************************
+        Realtime=21, UserTime=66, SystemTime=199, Combined=265
+Write 40:****************************************
+        Realtime=28, UserTime=80, SystemTime=226, Combined=306
+
+</pre>
+<hr>
+<a name="Alpha600"><h2>DEC AlphaStation 600 5/266</h2></a>
+5-40 64^3 double-precision float datasets were written
+(each '*' represents writing a single datasets)<p>
+Test performed on a DEC AlphaStation 600 5/266
+while the machine was moderately loaded.  The machine has 1 266 MHz
+Alpha ev 5 processor, 64Megabytes RAM.  A single SCSI-2 disk was used
+as the data drive for the test.   This is from a single run.
+More tests will be done to create an averaged score.<p>
+<pre>
+--------------IEEE--------------
+Write  5:*****
+        Realtime=1, UserTime=1, SystemTime=18, Combined=19
+Write 10:**********
+        Realtime=4, UserTime=0, SystemTime=43, Combined=43
+Write 15:***************
+        Realtime=6, UserTime=0, SystemTime=65, Combined=65
+Write 20:********************
+        Realtime=7, UserTime=0, SystemTime=82, Combined=82
+Write 25:*************************
+        Realtime=9, UserTime=0, SystemTime=109, Combined=109
+Write 30:******************************
+        Realtime=11, UserTime=1, SystemTime=146, Combined=147
+Write 35:***********************************
+        Realtime=12, UserTime=0, SystemTime=183, Combined=183
+Write 40:****************************************
+        Realtime=16, UserTime=1, SystemTime=196, Combined=197
+--------------HDF---------------
+Write  5:*****
+        Realtime=4, UserTime=71, SystemTime=30, Combined=101
+Write 10:**********
+        Realtime=8, UserTime=145, SystemTime=55, Combined=200
+Write 15:***************
+        Realtime=12, UserTime=218, SystemTime=84, Combined=302
+Write 20:********************
+        Realtime=14, UserTime=292, SystemTime=113, Combined=405
+Write 25:*************************
+        Realtime=19, UserTime=361, SystemTime=145, Combined=506
+Write 30:******************************
+        Realtime=22, UserTime=433, SystemTime=174, Combined=607
+Write 35:***********************************
+        Realtime=27, UserTime=503, SystemTime=202, Combined=705
+Write 40:****************************************
+        Realtime=30, UserTime=580, SystemTime=231, Combined=811
+-------------F77 Unformatted---------------
+Write  5:*****
+        Realtime=3, UserTime=11, SystemTime=21, Combined=32
+Write 10:**********
+        Realtime=3, UserTime=25, SystemTime=38, Combined=63
+Write 15:***************
+        Realtime=7, UserTime=37, SystemTime=59, Combined=96
+Write 20:********************
+        Realtime=8, UserTime=49, SystemTime=83, Combined=132
+Write 25:*************************
+        Realtime=10, UserTime=60, SystemTime=115, Combined=175
+Write 30:******************************
+        Realtime=12, UserTime=74, SystemTime=134, Combined=208
+Write 35:***********************************
+        Realtime=13, UserTime=86, SystemTime=154, Combined=240
+Write 40:****************************************
+        Realtime=15, UserTime=95, SystemTime=192, Combined=287
+</pre>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+<!-- Created: Wed May  7 12:28:58 MDT 1997 -->
+<!-- hhmts start -->
+Last modified: Wed Jun  4 10:19:46 CDT 1997
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/UCDwriter.html b/doc/html/UCDwriter.html
new file mode 100644
index 0000000..1dec11c
--- /dev/null
+++ b/doc/html/UCDwriter.html
@@ -0,0 +1,57 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>UCD Writer</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+      <h1>UCD Writer</h1>
+      
+      The UCD Writer stores finite-element cell-connectivity data.
+      The UCD format is used by popular FEM simulation packages like
+      ABAQUS and by visualization systems like AVS and Explorer.  It
+      is also a useful format to store AMR data into for visualization
+      systems since virtually no visualization system understands
+      heirarchial grids.<p>
+
+	The writer API has a lot of <b>beginSomething()</b> and
+	<b>endSomething()</b> statements.  This is because there may
+	be several independent lists of nodes and cells at a given
+	timestep in a completely arbitrary UCD dataset.  This
+	interface allows this to be dealt with in pieces.<p>
+
+      <h2>The API</h2>
+      <UL>
+	<LI><a href="#CPP">C++ Interface</a>
+	<LI><a href="#C">C Interface</a>
+	<LI><a href="#F77">F77/F90 Interface</a>
+      </UL>
+      <hr>
+      <a name="CPP">C++ Interface</a>
+      <DL>
+	<DT><i>constructor</i> <b>UCDwriter::UCDWriter(
+	    IObase &iofile,
+	    IObase::DataType defaultnodetype=IObase::Float32,
+	    IObase::DataType defaultcelltype=IObase::Int32
+	    )</b>
+	<DD>The <i>filehandle</i> is an already open IEEEIO or HDFIO
+	  file.  This initializes the reader and attaches it to that
+	  datafile. You can optionally set the datatype for the
+	  node/vertex coordinates and the cell indices.  Normally
+	  these would be Float32 and Int32 respectively. 
+	<DT><i>destructor</i> <b>UCDwriter::~UCDwriter()</b>
+	<DD>This flushes all of the necessary file buffers and
+	  destroys the UCDwriter object.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	<DT>
+      </DL>
+      
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+<!-- Created: Wed May  7 13:17:28 MDT 1997 -->
+<!-- hhmts start -->
+Last modified: Wed May  7 13:32:18 MDT 
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/Using.html b/doc/html/Using.html
new file mode 100644
index 0000000..f4c8c5e
--- /dev/null
+++ b/doc/html/Using.html
@@ -0,0 +1,68 @@
+<html>
+  <head>
+    <title>Using FlexIO</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+      <img src="Images/info.gif">
+      <hr>
+    <h1>Introduction</h1>
+    FlexIO borrows its terminology and storage-style from
+    HDF and NetCDF.  The file stores a sequence of multidimesional
+    arrays which are referred to generically as <b>datasets</b>.
+    The <b>rank</b> of the dataset is the number of dimensions the
+    data array has.  The <b>dimensions</b> themselves are stored as
+    an array of integers.  The dataset has a 
+    <a href="DataTypes.html"><b>datatype</b></a> which
+    identifies the type of data stored in the array {32-bit float,
+    64-bit float, 32-bit integer, 64-bit integer, character}.  The
+    datasets are stored sequentially in the file and can be accessed
+    by their index which ranges from 0 to (&ltnumber of datasets&gt -
+      1).<p> 
+	  
+      It is important to note that the data is always stored in
+      Fortan order.  That is, the first element of the
+      <b>dimensions</b> array always refers to the number of
+      elements that are most closely packed in the array
+      (eg. stride = 1).  The next dimension has a stride equal to
+      the product of the lower dimensions.  This is opposite of
+      default C/C++ array indexing order but can be accomodated
+      easily in those languages.<p> 
+      
+      In addition to raw dataset storage, you can attach
+      additional descriptions to the data using <b>annotations</b>
+      and <b>attributes</b>.<p>   
+      
+      An <b>annotation</b> is a text-string description of a
+      dataset which can be attached to dataset. You can use it to
+      add comments or other such information to the file.<p>
+      
+      An <b>attribute</b> is a named vector of data (of any type)
+      attached to a dataset.  This can function like an
+      <b>annotation</b> but it is primarily intended to add more
+      information to a dataset that can be interpreted by
+      visualization system or other such programs that would read
+      the datafile.  The type of data attached in an attribute can
+      be the <i>origin</i> in 3D space of the dataset or a list of
+      floating point coordinates.
+      <i>coordinates</i> or a <i>componentname</i> etc... The name
+      identifies the semantic meaning of the array's contents and
+      readers can be configured to look for particular names to
+      add descriptive information to the dataset.<p>.
+      
+	<hr>
+	<h1>Documentation</h1>
+	<UL>
+	  <LI><a href="UsingC++.html">Using the C++ interface</a>
+	  <LI><a href="UsingC.html">Using the C interface</a>
+	  <LI><a href="UsingF77.html">Using the F77 interface</a>
+	  <LI><a href="UsingIDL.html">Using the IDL interface</a> 
+	  <LI><a href="UsingJava.html">Using the Java interface</a>
+	</UL>
+	<hr>
+       	<address><a href="mailto:jshalf@ncsa.uiuc.edu">John Shalf</a></address>
+	<!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+	<!-- hhmts start -->
+Last modified: Thu Feb  4 21:38:53 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/UsingC++.html b/doc/html/UsingC++.html
new file mode 100644
index 0000000..15622d0
--- /dev/null
+++ b/doc/html/UsingC++.html
@@ -0,0 +1,442 @@
+<html>
+  <head>
+    <title>IEEE IO C++ Interface</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+    <table><tr>
+	  <td><img src="Images/info.gif"></td>
+	  <td><h1>C++</h1></td>
+	  </tr></table>
+	<hr>
+	<h1>Using the C++ Interface</h1>
+      To use the C++ interface, you must include the
+      headers <b>IO.hh</b> and <b>IEEEIO.hh</b>.  If you only require
+      the IEEEIO interface, you link only with <b>libieeeio.a</b> using
+      <code>-L$IEEE_DIRECTORY/lib -lieeeio</code>.<p>
+	
+	If you
+	also want HDF support you must also include the header
+	<b>HDFIO.hh</b> and link with <b>libhdfio.a</b> and
+	the usual complement of HDF libraries using
+	<code>-L$HDF_DIRECTORY/lib -L$IEEE_DIRECTORY/lib -lhdfio
+	  -lieeeio -lmfhdf -ldf -ljpeg -lz</code>.
+	<hr>
+	<h1>C++ Methods</h1>
+	<UL>
+	  <LI><a href="#Opening">Opening and Closing Datafiles</a>
+	  <LI><a href="#Writing">Writing Datasets</a>
+	  <LI><a href="#Reading">Reading Datasets</a>
+	  <LI><a href="#Seeking">Random Access to Datasets <i>(Seeking)</i></a>
+	  <LI><a href="#WriteAttribs">Writing Attributes</a>
+	  <LI><a href="#ReadAttribs">Reading Attributes</a>
+	  <LI><a href="#WriteAnn">Writing Annotations</a>
+	  <LI><a href="#ReadAnn">Reading Annotations</a>
+	  <LI><a href="#ReadWriteChunk">Writing and Reading in Chunks</a>
+	</UL>
+
+	<hr>
+	<a name="Opening"><h2>Opening</h2></a>
+	To open an IEEEIO file, you simply create a new IEEEIO object.
+       The constructor handles the opening.<p>
+      <b>C++ Prototype</b><br>
+      <code>IEEEIO::IEEEIO(char *filename,IObase::AccessMode accessmode);</code><br>
+      <DL>
+	<DT><i>filename</i>:
+	  <DD>The name of the IEEEIO data file to
+	  open.  The typical extension for these files is <i>.raw</i>
+	<DT><i>accessmode</i>:
+	  <DD>The accessmode for the file.  This is
+	  one of 3 different access modes
+	  <!--<DL>
+	    <DT><i>IObase::Read</i>:
+	    <DD>Opens a file in read-only mode.
+	    <DT><i>IObase::Create</i>:
+	    <DD>Opens a file in write-only mode.  If the file does not exist, it will be created.  If it does exist, it will be truncated.
+	    <DT><i>IObase::Append</i>: 
+	      <DD>Opens a file in read/write mode.  The file pointer is automatically placed at the end of the file for appending, but random-access read operations are allowed as well.
+	  </DL>-->
+	  <UL>
+	    <LI><b>IObase::Read</b>:
+	      Opens a file in read-only mode.
+	    <LI><b>IObase::Create</b>:
+	    Opens a file in write-only mode.  If the file does not exist, it will be created.  If it does exist, it will be truncated.
+	    <LI><b>IObase::Append</b>: 
+	      Opens a file in read/write mode.  The file pointer is automatically placed at the end of the file for appending, but random-access read operations are allowed as well.
+	  </UL>
+      </DL>
+      
+      Since this is inherited from the IO base class, you can assign
+      the newly created object to a pointer to the base class and
+      deal with it generically.<br>
+<pre>
+    IO *writer = new IEEEIO("datafileout.raw",IObase::Create);
+    IO *reader = new IEEEIO("datafilein.raw",IObase::Read);
+</pre><br>
+      You can test if the file was opened successfully using the IObase::isValid() method.<br>
+<pre>
+    if(!reader->isValid())
+       puts("The file you specified does not exist or is not in a readable format");
+</pre><br>
+      
+      Other IO systems can be inherited from the IO base class.  So
+    for instance, to read HDF files you simply link with the the HDFIO
+    and HDF libraries and open using;
+      <pre>
+    IO *writer = new HDFIO("datafileout.raw",IObase::Create);
+    IO *reader = new HDFIO("datafilein.raw",IObase::Read);
+      </pre>
+
+    After the files are opened, you can use the methods in the
+    baseclass IO to do all of your reading and writing in a completely
+    generic manner regardless of the implementation of the underlying
+    IO system so long as the underlying IO system implements the
+    methods of the base class.  There are plans, for example, to have
+    a SocketIO system that allows the data to be written out to a TCP
+    socket instead of to a file for real-time simulation-visualization
+    systems.  There are also plans to use this interface to drive an
+    existing Parallel IO system.<p>
+
+To close the file, you simply delete the object.
+<pre>
+   delete writer;
+   delete reader;
+</pre>
+	Since virtual destructors are used, you can delete them as
+    objects of the base IO class (no casts required).  
+
+      <hr>
+      <a name="Writing"><h2>Writing</h2></a>
+      To write data you simply use the method write().
+      <p><b>C++ Prototype</b><br>
+      <code>IEEEIO::write(IObase::DataType numbertype,int rank,int *dimensions,void *data);</code>
+      <DL>
+	  <DT><i>numbertype</i>:
+	  <DD>The type of the data being stored 
+	(as defined in <a href="DataTypes.html">DataType.html</a>).  
+	It can be one of
+	  <UL>
+	    <LI><b>IObase::Float32</b><br><i>32-bit single-precision IEEE float</i>
+	    <LI><b>IObase::Float64</b><br><i>64-bit double-precision IEEE float</i>
+	    <LI><b>IObase::Int8</b><br><i>byte</i>
+	    <LI><b>IObase::Int16</b><br><i>16-bit short integer</i>
+	    <LI><b>IObase::Int32</b><br><i>32-bit standard integer</i>
+	    <LI><b>IObase::Int64</b><br><i>64-bit long integer. (note:
+		this is not availible on the Intel/Windows
+		platform)</i>
+	    <LI><b>IObase::uInt8</b><br><i>unsigned character</i>
+	    <LI><b>IObase::uInt16</b><br><i>unsigned 16-bit short integer</i>
+	    <LI><b>IObase::uInt32</b><br><i>unsigned 32-bit standard integer</i>
+	    <LI><b>IObase::uInt64</b><br><i>unsigned 64-bit long integer. (note: this is not availible on the Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	  <DD>Number of dimensions of the dataset
+	  <DT><i>dimensions</i>:
+	  <DD>An array of <i>rank</i> integers that give the dimensions of the dataset
+	<DT><i>data</i>:
+	  <DD>Your data array. 
+	</DL>
+
+	  So to write a sample array of data.
+	<pre>
+	float myarray[40][50][60]; // our bogus data array
+	int rank=3;
+	int dims[3]={60,50,40}; // notice these are reversed.
+		// this is because ieeeio assumes f77 order for data 
+		// and c/c++ use exactly the opposite ordering for data in memory.
+	IO *writer=new IEEEIO("datafile.raw",IObase::Create); // create a outfile
+	writer->write(IObase::Float32,rank,dims,myarray); // write a dataset
+	. . . . you can write as many datasets as you want
+	delete writer; // then close the file
+	</pre>
+
+	<hr>
+	<a name="Reading"><h2>Reading Data</h2></a>
+	Reading is a two step process.  First you get information on
+      the size and type of the data you intend to read.  This allows
+      you to allocate an array of the proper size and type for the
+      reading.  Then you actually read the data into a pre-allocated
+      array.  The methods for this are readInfo() and read().<p>
+	<b>C++ Prototype</b><br>
+	<code>readInfo(IObase::DataType &numbertype,int &rank,int
+	  *dims,int maxdims=3);</code><p>
+      <DL>
+	<DT><i>numbertype</i>:
+	<DD>The type of the data being stored 
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>.  
+	It can be one of
+	  <UL>
+	    <LI><b>IObase::Float32</b><br><i>32-bit single-precision IEEE float</i>
+	    <LI><b>IObase::Float64</b><br><i>64-bit double-precision IEEE float</i>
+	    <LI><b>IObase::Int8</b><br><i>byte</i>
+	    <LI><b>IObase::Int16</b><br><i>16-bit short integer</i>
+	    <LI><b>IObase::Int32</b><br><i>32-bit standard integer</i>
+	    <LI><b>IObase::Int64</b><br><i>64-bit long integer. (note:
+		this is not availible on the Intel/Windows
+		platform)</i>
+	    <LI><b>IObase::uInt8</b><br><i>unsigned character</i>
+	    <LI><b>IObase::uInt16</b><br><i>unsigned 16-bit short integer</i>
+	    <LI><b>IObase::uInt32</b><br><i>unsigned 32-bit standard integer</i>
+	    <LI><b>IObase::uInt64</b><br><i>unsigned 64-bit long integer. (note: this is not availible on the Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	<DD>Number of dimensions of the dataset
+	<DT><i>dimensions</i>:
+	<DD>An array of <i>rank</i> integers that give the dimensions
+	  of the dataset
+	<DT><i>maxdims</i>:
+	<DD>The maximum size of the dimensions array you given it.
+	  This prevents array overruns if the dataset has more
+	  dimensions than you were anticipating.  The default is 3 but
+	  it can be any arbitrary positive integer.
+      </DL>
+      This retrieves information about the datatype, rank, 
+      and dimensions of the dataset to be retrieved.
+      By default the maximum size of the dimensions array is 3, 
+      but you can set it to be larger.<p>
+	<b>C++ Prototype</b><br>
+	<code>
+	IEEEIO::read(void *data);
+	</code><p>
+	This actually reads the dataset into the preallocated array <i>data</i>.<p>
+
+	  Another useful utility function is IObase::sizeOf() which returns the number of bytes in a give IObase:: datatype in manner analogous to the standard C sizeof() operator.
+
+	  So for instance, to read a simple dataset, you would do
+	<pre>
+	int rank;
+	IObase::DataType numbertype;
+	int dims[3];
+	float *data; // assumes float data
+	IO *infile = new IEEEIO("dataset.raw",IObase::Read);
+	infile-&gtreadInfo(numbertype,rank,dims);
+	// OK, we are assuming a 3D IObase::Float32 array, 
+	// but you can be more sophisticated...
+	data = new char[IObase::nBytes(numbertype,rank,dims)];
+        // You can also use
+        // data = new float[IObase::nElements(rank,dims)];
+	infile-&gtread(data); // read in the data
+	</pre><p>
+
+	  Since multiple datasets can be stored in a file, you can
+	retrieve them in the order they were written <i>(there is a <a
+href="#Seeking">seek()</a> function that allows random access as well)</i>.  The method <b>readInfo()</b> implies reading the next dataset stored in the file.  The method <b>nDatasets()</b> tells how many datasets are in a file. So typically if you want to read all datasets in a file in order, you would use code similar to;
+	<pre>
+	IO *infile = new IEEEIO("dataset.raw",IObase::Read);
+	for(int i=0;i&ltinfile-&gtnDatasets();i++){
+	  .....lots of code....
+	  infile->readInfo(numbertype,rank,dims); // increments to next dataset
+	  .....more code....
+	}
+	</pre>
+
+      <hr>
+      <a name="Seeking"><h2>Random Access to Datasets
+	  <i>(Seeking)</i></h2></a>
+      You can select specific datasets in a file using the seek()
+      method.<p>
+	<b>C++ Prototype</b>
+	<code>IEEEIO::seek(int index)</code>
+	<DL>
+	<DT><b>index</b>
+	<DD>The index of the dataset you want to read from.  This can
+	  be any number from 0 to (number_of_datasets - 1).
+      </DL>
+      
+      <hr>
+      <a name="WriteAttribs"><h2>Writing Attributes</h2></a>
+	  Attributes allow you to attach extra information to each
+      dataset stored in the file.  Each attribute has a name and an
+      array of data (of any of the standard IObase:: types) stored with
+      it.  These attributes can be retrieved by name or by integer
+      index in the order in which they were stored.  A typical
+      attribute would typically be parameters that describe the grid
+      or the data like, "origin" which would be the 3-vector of floats
+      which locates of the origin of a grid in 3-space.  The method
+      used to write these attributes is writeAttribute();<p>
+	<b>C++ Prototype</b><br>
+      <code>
+	IEEEIO::writeAttribute(char *name,IObase::DataType numbertype,int length,void *data)
+      </code><p>
+      <DL>
+	<DT><i>name</i>:
+	<DD>Name of the attribute (like "origin" or "coordinates")
+	<DT><i>numbertype</i>:
+	<DD>The type of the data array associated with the attribute 
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the data array.
+	<DT><i>data</i>:
+	<DD>The attribute data.
+      </DL><p>
+	    So to write an attribute named <i>origin</i> along with a 3-vector float for the coordinates of the origin, you would use;
+	  <pre>
+	float origin[3]={5.1,0.3,0.5};
+	// and assuming the file is already open for writing
+	// the following attribute will be attached to the last 
+	// written dataset. (you must have write data before adding attribs)
+	writer->writeAttribute("origin",IObase::Float32,3,origin);
+	  </pre>
+
+      <hr>
+      <a name="ReadAttribs"><h2>Reading Attributes</h2></a>
+      The attributes can be retrieved in the order they were written
+      or they can be retrieved by their name.  To retrieve the
+      attributes in order, you would utilize the <b>nAttributes()</b>
+      method to determine how many attributes are attached,
+      <b>readAttributeInfo()</b> to get the size and type of the
+      attribute, and <b>readAttribute()</b> to read the attribute
+      data.<p>
+	<b>C++ Prototype</b><br>
+	<code>int IEEEIO::nAttributes()</code><p>
+      <DL>
+	<DT><i>returnvalue</i>:
+	<DD>Number of attributes in the file
+      </DL><p>
+	<b>C++ Prototype</b><br>
+	<code>IEEEIO::readAttributeInfo(int index,char *name,IObase::DataType &numbertype,int &length,int maxnamelength=128);
+	</code>
+      <DL>
+	<DT><i>index</i>:
+	<DD>The index of the attribute which can be 0 to (nattributes-1)
+	<DT><i>name</i>:
+	<DD>A buffer in which the name of the attribute will be placed.
+	<DT><i>numbertype</i>:
+	<DD>The type of the attribute data 
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the attribute data.
+	<DT><i>maxnamelength</i>:<DD>The maximum size of a name that can be stored in the <b>name</b> buffer.  The default maximum is 128, but can be set to any size.
+      </DL>
+<p>
+	<b>C++ Prototype</b><br>
+	<code>IEEEIO::readAttribute(int index,void *data);</code>
+      <DL>
+	<DT><i>index</i>:
+	<DD>The index of the attribute data to read
+	<DT><i>data</i>:
+	<DD>The array into which the attribute data is copied.
+      </DL>
+      So for example, to read the attributes in order, you can use
+      <pre>
+	for(int i=0;i&ltinfile-&gtnAttributes();i++){
+	    char name[128];
+	    int length;
+	    IObase::DataType datatype;
+	    ...
+	    infile->readAttributeInfo(i,name,datatype,length);
+	    ... // allocate some data for storage
+	    infile->readAttribute(i,data);
+	}
+	  </pre><p>
+
+	      The attributes can also be retrieve by name.  In fact,
+      the is the most likely way you will use the attibutes interface.
+      The readAttributeInfo() method is overloaded to allow retrieval
+      by name as well.  It returns the index of the attribute if one
+      is found with a matching name: it returns -1 if one is not
+      found.
+	    <p><b>C++ Prototype</b><br>
+	<code>
+	int IEEEIO::readAttributeInfo(char *name,IObase::DataType &numbertype,int &length);
+      </code>
+      <DL>
+	<DT><i>returnvalue</i>:
+	<DD>The index of the attribute if found or -1 if no attribute with matching name is found.
+	<DT><i>name</i>:
+	<DD>The name of the attribute to find.
+	<DT><i>numbertype</i>:
+	<DD>Returns the numbertype of the stored attribute data
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>he length of the stored attribute data.
+      </DL>
+	    So a typical use of this interface would be to find an attribute named "origin" and retrieve its data if it exists.
+	    <pre>
+	int index = infile->readAttributeInfo("origin",datatype,length);
+	if(index>=0) // the attribute exists
+		infile->readAttribute(index,data);
+	else 
+		puts("The attribute origin could not be found");
+	    </pre>
+
+	  </pre>
+
+	    <hr>
+	    <a name="WriteAnn"><h2>Writing Annotations</h2></a>
+      An annotation is a text string which can be used to
+      describe a dataset.  To write an annotation, you use the
+      writeAnnotation() method.<p>
+	<b>C++ Prototype</b><br>
+	<code>
+	  IEEEIO::writeAnnotation(char *annotationtext)
+	</code>
+      <DL>
+	<DT><i>annotationtext</i>:
+	<DD>A null terminated string of the annotation text
+      </DL>
+      The annotation will be attached to the last written dataset.
+      You can store more than one annotation per dataset and the
+      annotations can be of arbitrary length.<p>
+
+      <hr>
+      <a name="ReadAnn"><h2>Reading Annotations</h2></a>
+      The annotations are stored in the order they are written.  The
+      method <b>nAnnotations()</b> is used to find out how many
+      attributes are attached to a dataset.  The method
+      <b>readAnnotationInfo()</b> is used to find the length of the
+      annotation and <b>readAnnotatin()</b> reads the actual
+      annotation text.<p>
+	<b>C++ Prototype</b><br>
+      <code>
+	int nAnnotations();
+      </code>
+      <DL>
+	<DT><i>returnvalue</i>:
+	  <DD>Number of annotations attached to current dataset.
+      </DL><p>
+      <b>C++ Prototype</b><br><code>
+	readAnnotationInfo(int index,int &length)
+      </code>
+      <DL>
+	<DT><i>index</i>:
+	<DD>Index of the annotations which can be 0 to (nannotations-1)
+	<DT><i>length</i>:
+	<DD>Length in characters of the annotation.  This includes the null-terminating character.
+      </DL>
+      <hr>
+      <a name="ReadWriteChunk"><h2>Writing and Reading in Chunks</h2></a>
+      For distributed-memory programming paradigms like HPF, MPI, or
+      PVM, it is often not unfeasible to write data to disk in a
+      single operation.  For this reason, a <i>chunking</i> interface
+      is provided which allows you to write data in blocks to the
+      disk.<p>
+	To begin a chunk writing operation, you must first reserve a
+	data chunk in the file.  This is accomplished using <b>reserveChunk()</b>
+	<b>C++ Prototype</b><br>
+	<code>IObase::reserveChunk(IObase::DataType datatype,int rank,int *dims);
+	</code><p>
+		Once space has been allocated in the datafile, you can write
+	blocks of data specified by their dimensions and origin using
+	<b>writeChunk()</b>
+	<b>C++ Prototype</b><br>
+	<code>
+	  int IObase::IOwriteChunk(int *dims,int *origin,void *data);
+	</code><p>
+	Likewise, it is possible to read chunks from the disk as
+	well.  No special procedure is required to select a record to
+	read in chunks. Simply use <a href="#Reading">readInfo()</a> 
+	to get the dimensions and
+	type of the dataset and then use <b>readChunk()</b> in place
+	of <b>read()</b> in order to read-in the data.
+	<b>C++ Prototype</b><br>
+	<code>
+	  int IObase::readChunk(int *dims,int *origin,void *data);
+	</code><p>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Thu Feb  4 21:53:13 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/UsingC.html b/doc/html/UsingC.html
new file mode 100644
index 0000000..3acab85
--- /dev/null
+++ b/doc/html/UsingC.html
@@ -0,0 +1,505 @@
+<html>
+  <head>
+    <title>IEEEIO C Interface</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+      <table><tr>
+	  <td><img src="Images/info.gif"></td>
+	  <td><h1>ANSI  and K&R C</h1></td>
+	</tr></table>
+      <hr>
+      <h1>Using the C Interface</h1>
+      To use the C interface, you must include the
+      headers <b>IO.h</b> and <b>IEEEIO.h</b>.  By default the headers
+      are treated as K&R C (eg. no prototypes) because that is the
+      default of for many workstation C compilers.  To enable the ANSI
+      C prototypes compile with -DANSI or use <b>#define ANSI</b> in
+      your source files before you include the <b>IO.h</b> and
+      <b>IEEEIO.h</b> headers.  If you only require
+      the IEEEIO interface, you link only with <b>libieeeio.a</b> using
+      <code>-L$IEEE_DIRECTORY/lib -lieeeio</code><p>
+	
+	If you also want HDF support you must also include the header
+	<b>HDFIO.hh</b> and link with <b>libhdfio.a</b> and
+	the usual complement of HDF libraries using
+	<code>-L$HDF_DIRECTORY/lib -L$IEEE_DIRECTORY/lib -lhdfio -lieeeio -lmfhdf -ldf -ljpeg -lz</code><p>
+
+      <hr>
+      <h1>C Subroutines</h1>
+      <UL>
+	<LI><a href="#Opening">Opening and Closing Datafiles</a>
+	<LI><a href="#Writing">Writing Datasets</a>
+	<LI><a href="#Reading">Reading Datasets</a>
+	<LI><a href="#Seeking">Random Access to Datasets
+	    <i>(Seeking)</i></a>
+	<LI><a href="#WriteAttribs">Writing Attributes</a>
+	<LI><a href="#ReadAttribs">Reading Attributes</a>
+	<LI><a href="#WriteAnn">Writing Annotations</a>
+	<LI><a href="#ReadAnn">Reading Annotations</a>
+	<LI><a href="#ReadWriteChunk">Writing and Reading in Chunks</a>
+      </UL>
+
+      <hr>
+      <a name="Opening"><h2>Opening</h2></a>
+      Just like the familiar <b>FILE*</b> type for C stdio operations, all
+      IEEEIO operations require a file handle.  The type of this handle is
+      IOFile (and 8-byte integer number).  The <b>IEEEopen()</b> and
+	<b>HDFIOopen()</b> 
+      routines are used to create this handle and the IOclose() subroutine can
+      be used to close file handles of either type.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>IOFile IEEEopen(char *filename,char *accessmode);</code><br>
+      <DL>
+	<DT><i>filename</i>:
+	<DD>The name of the IEEEIO data file to
+	  open.  The typical extension for these files is <i>.raw</i>
+	<DT><i>accessmode</i>:
+	<DD>The accessmode for the file.  This is
+	  one of 3 different access modes
+	  <UL>
+	    <LI><b>"read"</b>:<i>Opens a file in read-only mode.  This
+	      can also be selected using any of the standard fopen()
+		modes; "r" and "rb"</i>
+	    <LI><b>"write"</b>:<i>Opens a file in write-only mode.  If the
+		file does not exist, it will be created.  If it does exist, it will be
+		truncated. This
+	      can also be selected using any of the standard fopen()
+		modes; "w","wb","w+","w+b", and "wb+"</i>
+	    <LI><b>"append"</b>: <i>Opens a file in read/write mode.  The file
+		pointer is automatically placed at the end of the file for appending,
+		but random-access read operations are allowed as well.This
+		can also be selected using any of the standard fopen()
+		modes; "a","ab","a+","a+b", and "ab+"</i>
+	  </UL>
+      </DL>
+      
+      After you open the file handle you can use the same set of 
+      subroutines for operations on the file regardless of whether the
+      file is HDF or IEEEIO.  The libraries manage all of this internally.  So
+      the open step is the only thing that is important to differentiating
+      between your HDF and IEEEIO files.
+      There are plans, for example, to have a SocketIO system
+      that allows the data to be written out to a TCP socket instead of to a
+      file for real-time simulation-visualization systems.  There are also
+      plans to use this interface to drive an existing Parallel IO
+      system.<p><br>
+      <pre>
+	/* write an IEEEIO file */
+    IOFile writer = IEEEopen("datafileout.raw","write"); 
+	/* write an HDF file */
+    IOFile writer = HDFIOopen("datafileout.raw","w"); /* "w" is also valid */
+	/* another way to open for writing */
+    IOFile writer = IEEEopenWrite("datafileout.raw");
+    /* open HDF file for reading */ 
+    IOFile reader = HDFIOopen("datafilein.raw","read"); 
+    /* another way to open an HDF file for reading */
+    IOFile reader = HDFIOopenRead("datafileout.raw");
+    /* another way to open an IEEEIO file for reading */
+    IOFile reader = IEEEopenRead("datafileout.raw"); 
+      </pre><p>
+
+	You can test if the file was opened successfully using the
+	IOisValid() function.<br>
+      <pre>
+    IOFile fileID = IEEEopen("datafileout.raw","write");
+    if(!IOisValid(fileID))
+       puts("The file you specified does not exist or is not in a
+readable format");
+      </pre><br>
+
+      To close the file, you simply use IOclose.
+      <pre>
+   IOclose(IOFile filehandle);
+      </pre>
+
+
+      <hr>
+      <a name="Writing"><h2>Writing</h2></a>
+      To write data you simply use the method write().
+      <p><b>ANSI C Prototype</b><br>
+	<code>int IOwrite(IOFile filehandle,int numbertype,int rank,int
+	  *dimensions,void *data);</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>numbertype</i>:
+	<DD>The type of the data being stored 
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>.  
+	It can be one of
+	  <UL>
+	    <LI><b>FLOAT32</b><br><i>32-bit single-precision IEEE
+		float</i>
+	    <LI><b>FLOAT64</b><br><i>64-bit double-precision IEEE
+		float</i>
+	    <LI><b>STRING</b><br><i>Character string.  This is
+	      null-terminated automatically by the API.  This is
+	      interpreted differently from the <b>byte</b> datatype
+	      which is raw data.</i>
+	    <LI><b>INT8</b><br><i>byte</i>
+	    <LI><b>INT16</b><br><i>16-bit short integer</i>
+	    <LI><b>INT32</b><br><i>32-bit standard integer</i>
+	    <LI><b>INT64</b><br><i>64-bit long integer. (note: this is not
+		availible on the Intel/Windows platform because it
+	      does not allow 64-bit integers)</i>
+	    <LI><b>UINT8</b><br><i>unsigned character</i>
+	    <LI><b>UINT16</b><br><i>unsigned 16-bit short integer</i>
+	    <LI><b>UINT32</b><br><i>unsigned 32-bit standard integer</i>
+	    <LI><b>UINT64</b><br><i>unsigned 64-bit long
+		integer. (note: this is not availible on the
+		Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	<DD>Number of dimensions of the dataset
+	<DT><i>dimensions</i>:
+	<DD>An array of <i>rank</i> integers that give the dimensions of
+	  the dataset
+	<DT><i>data</i>:
+	<DD>Your data array. 
+      </DL>
+
+      So to write a sample array of data.
+      <pre>
+	float myarray[40][50][60]; /* our bogus data array */
+	int i,rank=3;
+	int dims[3]={60,50,40}; /* notice these are reversed. */
+		/* this is because ieeeio assumes f77 order for data 
+		  and c/c++ use exactly the opposite ordering for data in */
+memory.
+	IOFile writer=IEEEopen("datafile.raw","write"); /* create a outfile */
+	for(i=0;i&ltndatasets;i++){
+		. . . . computation . . .
+		IOwrite(writer,FLOAT32,rank,dims,myarray); /* write a dataset */
+		. . . . you can write as many datasets as you want
+	}
+	IOclose(writer); /* then close the file */
+      </pre>
+
+      <hr>
+      <a name="Reading"><h2>Reading Data</h2></a>
+      Reading is a two step process.  First you get information on
+      the size and type of the data you intend to read.  This allows
+      you to allocate an array of the proper size and type for the
+      reading.  Then you actually read the data into a pre-allocated
+      array.  The methods for this are <b>IOreadInfo()</b> and
+      <b>IOread()</b>.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>int IOreadInfo(IOFile filehandle,int *numbertype,int *rank,int
+	  *dims,int maxdims);</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>A filehandle open for reading or appending.
+	<DT><i>numbertype</i>:
+	<DD>The type of the data being stored 
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>.  
+	It can be one of
+	  <UL>
+	    <LI><b>FLOAT32</b><br><i>32-bit single-precision IEEE float</i>
+	    <LI><b>FLOAT64</b><br><i>64-bit double-precision IEEE float</i>
+	    <LI><b>INT8</b><br><i>byte</i>
+	    <LI><b>INT16</b><br><i>16-bit short integer</i>
+	    <LI><b>INT32</b><br><i>32-bit standard integer</i>
+	    <LI><b>INT64</b><br><i>64-bit long integer. (note: this is not
+		availible on the Intel/Windows platform)</i>
+	    <LI><b>UINT8</b><br><i>unsigned character</i>
+	    <LI><b>UINT16</b><br><i>unsigned 16-bit short integer</i>
+	    <LI><b>UINT32</b><br><i>unsigned 32-bit standard integer</i>
+	    <LI><b>UINT64</b><br><i>unsigned 64-bit long integer. (note: this is not availible on the Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	<DD>Number of dimensions of the dataset
+	<DT><i>dimensions</i>:
+	<DD>An array of <i>rank</i> integers that give the dimensions
+	  of the dataset
+	<DT><i>maxdims</i>:
+	<DD>The maximum size of the dimensions array you given it.
+	  This prevents array overruns if the dataset has more
+	  dimensions than you were anticipating.  It can be any positive
+	  integer.
+      </DL>
+      This retrieves information about the datatype, rank, 
+      and dimensions of the dataset to be retrieved.
+      By default the maximum size of the dimensions array is 3, 
+      but you can set it to be larger.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOread(IOFile filehandle,void *data);
+	</code><p>
+	This actually reads the dataset into the preallocated array
+	<i>data</i>.<p>
+
+	Another useful utility function is IOsizeOf() which returns the
+	number of bytes in a give IO datatype in manner analogous to the
+	standard C sizeof() operator.
+
+	So for instance, to read a simple dataset, you would do
+      <pre>
+	int rank;
+	int numbertype;
+	int dims[3];
+	float *data; /* assumes float data */
+	IOFile infile = IEEEopen("dataset.raw","read");
+	IOreadInfo(infile,&numbertype,&rank,dims);
+	/* OK, we are assuming a 3D IO::Float32 array, 
+	 but you can be more sophisticated... */
+        data = (float*)malloc(IOnBytes(numbertype,rank,dims));
+        /* nBytes() is a convenience function... you could also use
+           data = (float*)malloc(dims[0] * dims[1] * dims[2] * IOsizeOf(numbertype)); */
+	IOread(infile,data); /* read in the data */
+      </pre><p>
+
+	Since multiple datasets can be stored in a file, you can
+	retrieve them in the order they were written <i>(there is a <a
+	    href="#Seeking">seek()</a> function that allows random access as
+	  well)</i>.  The method <b>readInfo()</b> implies reading the next
+	dataset stored in the file.  The method <b>nDatasets()</b> tells how
+	many datasets are in a file. So typically if you want to read all
+	datasets in a file in order, you would use code similar to;
+      <pre>
+	IOFile infile = IEEEopen("dataset.raw","r");
+	for(int i=0;i&lt IOnDatasets(infile);i++){
+	  .....lots of code....
+	  IOreadInfo(infile,&numbertype,&rank,dims); /* increments to next dataset */
+	  .....more code....
+	}
+      </pre>
+
+      <hr>
+      <a name="Seeking"><h2>Random Access to Datasets
+	  <i>(Seeking)</i></h2></a>
+      You can select specific datasets in a file using the seek()
+      method.<p>
+	<b>ANSI C Prototype</b>
+	<code>int IOseek(IOFile filehandle,int index)</code>
+      <DL>
+	<DT><i>filehandle</i>:
+	<DD>Handle to a file open for reading.
+	<DT><i>index</i>:
+	<DD>The index of the dataset you want to read from.  This can
+	  be any number from 0 to (number_of_datasets - 1).
+      </DL>
+      
+      <hr>
+      <a name="WriteAttribs"><h2>Writing Attributes</h2></a>
+      Attributes allow you to attach extra information to each
+      dataset stored in the file.  Each attribute has a name and an
+      array of data (of any of the standard IO datatypes) stored with
+      it.  These attributes can be retrieved by name or by integer
+      index in the order in which they were stored.  A typical
+      attribute would typically be parameters that describe the grid
+      or the data like, "origin" which would be the 3-vector of floats
+      which locates of the origin of a grid in 3-space.  The method
+      used to write these attributes is <b>IOwriteAttribute()</b>.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOwriteAttribute(IOFile filehandle,char *name,int numbertype,int
+	  length,void *data)
+	</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>name</i>:
+	<DD>Name of the attribute (like "origin" or "coordinates")
+	<DT><i>numbertype</i>:
+	<DD>The type of the data array associated with the attribute
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the data array.
+	<DT><i>data</i>:
+	<DD>The attribute data.
+      </DL><p>
+	So to write an attribute named <i>origin</i> along with a
+	3-vector float for the coordinates of the origin, you would use;
+      <pre>
+	float origin[3]={5.1,0.3,0.5};
+	/* and assuming the file is already open for writing
+	 the following attribute will be attached to the last 
+         written dataset. (you must have write data before adding
+         attribs) */
+	IOwriteAttribute(writer,"origin",FLOAT32,3,origin);
+      </pre>
+
+      <hr>
+      <a name="ReadAttribs"><h2>Reading Attributes</h2></a>
+      The attributes can be retrieved in the order they were written
+      or they can be retrieved by their name.  To retrieve the
+      attributes in order, you would utilize the <b>IOnAttributes()</b>
+      method to determine how many attributes are attached,
+      <b>IOreadIndexedAttributeInfo()</b> to get the size and type of the
+      attribute based on its index (<i>use IOreadAttributeInfo() to get size
+	and type for the attribute based on its name</i>), 
+	and <b>IOreadAttribute()</b> to read the attribute
+      data.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>int IOnAttributes()</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>Number of attributes in the file
+      </DL><p>
+	<b>ANSI C Prototype</b><br>
+	<code>int IOreadIndexedAttributeInfo(IOFile filehandle,int index,char *name,int *numbertype,int *length,int maxnamelength);
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>index</i>:
+	<DD>The index of the attribute which can be 0 to (nattributes-1)
+	<DT><i>name</i>:
+	<DD>A buffer in which the name of the attribute will be placed.
+	<DT><i>numbertype</i>:
+	<DD>The type of the attribute data
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the attribute data.
+	<DT><i>maxnamelength</i>:<DD>The maximum size of a name that can be
+	  stored in the <b>name</b> buffer.  It can be any positive integer.
+      </DL>
+      <p>
+	<b>ANSI C Prototype</b><br>
+	<code>int IOreadAttribute(IOFile filehandle,int index,void
+	  *data);</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>index</i>:
+	<DD>The index of the attribute data to read
+	<DT><i>data</i>:
+	<DD>The array into which the attribute data is copied.
+      </DL>
+      So for example, to read the attributes in order, you can use
+      <pre>
+	for(int i=0;i&ltIOnAttributes(infile);i++){
+	    char name[128];
+	    int length,datatype;
+	    ...
+	    IOreadIndexedAttributeInfo(infile,i,name,&datatype,&length,128);
+	    ... allocate some data for storage
+	    IOreadAttribute(infile,i,data);
+	}
+      </pre><p>
+
+	The attributes can also be retrieve by name.  In fact, the is
+	the most likely way you will use the attributes interface.  The
+	<b>IOreadAttributeInfo()</b> method is overloaded to allow retrieval by
+	name as
+	well.  It returns the index of the attribute if one is found with a
+	matching name: it returns -1 if one is not found.
+      <p><b>ANSI C Prototype</b><br>
+	<code>
+	  int IOreadAttributeInfo(char *name,int *numbertype,int *length);
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>The index of the attribute if found or -1 if no attribute with
+	  matching name is found.
+	<DT><i>name</i>:
+	<DD>The name of the attribute to find.
+	<DT><i>numbertype</i>:
+	<DD>Returns the numbertype of the stored attribute data
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>he length of the stored attribute data.
+      </DL>
+      So a typical use of this interface would be to find an attribute
+      named "origin" and retrieve its data if it exists.
+      <pre>
+	int index = IOreadAttributeInfo(infile,"origin",&datatype,&length);
+	if(index>=0) /* the attribute exists */
+		IOreadAttribute(infile,index,data);
+	else
+		puts("The attribute origin could not be found");
+      </pre>
+
+    </pre>
+
+      <hr>
+      <a name="WriteAnn"><h2>Writing Annotations</h2></a>
+      An annotation is a text string which can be used to
+      describe a dataset.  To write an annotation, you use the
+      writeAnnotation() method.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOwriteAnnotation(IOFile filehandle,char *annotationtext)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>annotationtext</i>:
+	<DD>A null terminated string of the annotation text
+      </DL>
+      The annotation will be attached to the last written dataset.
+      You can store more than one annotation per dataset and the
+      annotations can be of arbitrary length.<p>
+
+      <hr>
+      <a name="ReadAnn"><h2>Reading Annotations</h2></a>
+      The annotations are stored in the order they are written.  The
+      method <b>nAnnotations()</b> is used to find out how many
+      attributes are attached to a dataset.  The method
+      <b>readAnnotationInfo()</b> is used to find the length of the
+      annotation and <b>readAnnotatin()</b> reads the actual
+      annotation text.<p>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOnAnnotations(IOFile filehandle);
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>Number of annotations attached to current dataset.
+      </DL><p>
+	<b>ANSI C Prototype</b><br><code>
+	  IOreadAnnotationInfo(IOFile filehandle,int index,int *length)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>index</i>:
+	<DD>Index of the annotations which can be 0 to (nannotations-1)
+	<DT><i>length</i>:
+	<DD>Length in characters of the annotation.  This includes the
+	  null-terminating character.
+      </DL>
+      <hr>
+      <a name="ReadWriteChunk"><h2>Writing and Reading in Chunks</h2></a>
+      For distributed-memory programming paradigms like HPF, MPI, or
+      PVM, it is often not unfeasible to write data to disk in a
+      single operation.  For this reason, a <i>chunking</i> interface
+      is provided which allows you to write data in blocks to the
+      disk.<p>
+	To begin a chunk writing operation, you must first reserve a
+	data chunk in the file.  This is accomplished using <b>IOreserveChunk()</b>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOreserveChunk(IOFile filehandle,int datatype,int rank,int *dims);
+	</code><p>
+	Once space has been allocated in the datafile, you can write
+	blocks of data specified by their dimensions and origin using
+	<b>IOwriteChunk()</b>
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOwriteChunk(IOFile filehandle,int *dims,int *origin,void *data);
+	</code><p>
+	Likewise, it is possible to read chunks from the disk as
+	well.  No special procedure is required to select a record to
+	read in chunks. Simply use <a href="#Reading">IOreadInfo()</a> 
+	to get the dimensions and
+	type of the dataset and then use <b>IOreadChunk()</b> in place
+	of <b>IOread()</b> in order to read-in the data.
+	<b>ANSI C Prototype</b><br>
+	<code>
+	  int IOreadChunk(IOFile filehandle,int *dims,int *origin,void *data);
+	</code><p>
+	<hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John
+	  Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Thu Feb  4 21:58:57 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/UsingF77.html b/doc/html/UsingF77.html
new file mode 100644
index 0000000..5118411
--- /dev/null
+++ b/doc/html/UsingF77.html
@@ -0,0 +1,532 @@
+<html>
+  <head>
+    <title>IEEEIO F77 Interface</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+      <table><tr>
+	  <td><img src="Images/info.gif"></td>
+	  <td><h1>Fortran77</h1></td>
+	</tr></table>
+      <hr>
+      <h1>Using the F77 Interface</h1>
+      To use the F77 interface you must link to <b>ieeeio.a</b> and
+    the C++ libraries using
+    <DL>
+      <DT><b>All machines except SGI Irix 6.4</b>
+      <DD>f77</code> <i>link_line_stuff</i> <code>-L$IEEE_DIRECTORY/lib
+    -lieeeio -lC -lc</code>
+      <DT><b>SGI machines running Irix 6.4</b> <i>(eg. O2k and
+	  Octane)</i>
+      <DD>f77</code> <i>link_line_stuff</i> <code>-L$IEEE_DIRECTORY/lib
+    -lieeeio -lC -lCsup -lc</code>
+    </DL>
+    The <code>-lC</code> and <code>-lc</code> links in the C and C++
+    libraries with the fortran libraries.  Irix 6.4 also requires
+    <code>-lCsup</code> for reasons I do not know.<p>
+	
+	If you
+	also want HDF support you must also link with <b>libhdfio.a</b> and
+	the usual complement of HDF libraries using
+	<code>-L$HDF_DIRECTORY/lib -L$IEEE_DIRECTORY/lib -lhdfio
+	  -lieeeio -lmfhdf -ldf -ljpeg -lz</code>.
+      <hr>
+      <h1>F77 Subroutines</h1>
+      <UL>
+	<LI><a href="#Opening">Opening and Closing Datafiles</a>
+	<LI><a href="#Writing">Writing Datasets</a>
+	<LI><a href="#Reading">Reading Datasets</a>
+	<LI><a href="#Seeking">Random Access to Datasets
+	    <i>(Seeking)</i></a>
+	<LI><a href="#WriteAttribs">Writing Attributes</a>
+	<LI><a href="#ReadAttribs">Reading Attributes</a>
+	<LI><a href="#WriteAnn">Writing Annotations</a>
+	<LI><a href="#ReadAnn">Reading Annotations</a>
+	<LI><a href="#ReadWriteChunk">Writing and Reading in Chunks</a>
+      </UL>
+
+      <hr>
+      <a name="Opening"><h2>Opening</h2></a>
+      Just like the familiar <b>FILE*</b> type for F77 stdio operations, all
+      IEEEIO operations require a file handle.  The type of this handle is
+      INTEGER*8 (and 8-byte integer number).  The ieee_open() and hdf_open()
+      routines are used to create this handle and the io_close() subroutine can
+      be used to close file handles of either type.<p>
+	<b>F77 Call Format</b><br>
+	<code>INTEGER*8 ieee_open(CHARACTER filename(*),CHARACTER accessmode(*))</code><br>
+	<code>INTEGER*8 ieee_openr(CHARACTER filename(*))</code><br>
+	<code>INTEGER*8 ieee_openw(CHARACTER filename(*))</code><br>
+	<code>INTEGER*8 ieee_opena(CHARACTER filename(*))</code><br>
+      <DL>
+	<DT><i>filename</i>:
+	<DD>The name of the IEEEIO data file to
+	  open.  The typical extension for these files is <i>.raw</i>.
+	  <DT><i>accessmode</i>
+	  <DD>This is the type of access for the file.  You can either
+	  pass an accesstype option to the function or use the
+	  appropriately
+	  named function for the type of access you desire.
+	  <UL>
+	    <LI><b>openr = 'READ'</b>:<i>Opens a file in read-only mode.</i>
+	    <LI><b>openw = 'WRITE'</b>:<i>Opens a file in write-only mode.  If the
+		file does not exist, it will be created.  If it does exist, it will be
+		truncated.</i>
+	    <LI><b>opena = 'APPEND'</b>: <i>Opens a file in read/write mode.  The file
+		pointer is automatically placed at the end of the file for appending,
+		but random-access read operations are allowed as well.</i>
+	  </UL>
+      </DL>
+      
+      After you open the file handle you can use the same set of 
+      subroutines for operations on the file regardless of whether the
+      file is HDF or IEEEIO.  The libraries manage all of this internally.  So
+      the open step is the only thing that is important to differentiating
+      between your HDF and IEEEIO files.
+      There are plans, for example, to have a SocketIO system
+      that allows the data to be written out to a TCP socket instead of to a
+      file for real-time simulation-visualization systems.  There are also
+      plans to use this interface to drive an existing Parallel IO
+      system.<p><br>
+      <pre>
+c The file handles are INTEGER*8's
+    INTEGER*8 writer
+    INTEGER*8 reader
+c open a file for writing
+    writer = ieee_openw('datafileout.raw')
+c open an HDF file for writing
+    writer = hdf_openw('datafileout.raw')
+c open HDF file for reading  
+    reader = hdf_openr('datafilein.raw')
+c open an IEEEIO file for reading
+    reader = ieee_openr('datafileout.raw')
+      </pre><p>
+
+	You can test if the file was opened successfully using the
+	<b>io_isvalid()</b> function.<br>
+      <pre>
+    IF io_isvalid(infile).EQ.0 THEN
+    	write(*) 'The file you specified does not exist or is not in a
+readable format'
+      </pre><br>
+
+      To close the file, you simply use io_close.
+      <pre>
+   INTEGER io_close(INTEGER*8 filehandle)
+      </pre>
+
+      <hr>
+      <a name="Writing"><h2>Writing</h2></a>
+      To write data you simply use the method write().
+      <p><b>F77 Call Format</b><br>
+	<code>INTEGER io_write(INTEGER*8 filehandle,INTEGER numbertype,INTEGER rank,INTEGER
+	  dimensions(*),<i>type</i> data(*))</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>numbertype</i>:
+	<DD>The type of the data being stored
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>.  
+	It can be one of
+	  <UL>
+	    <LI><b>INT8=0</b><br><i>CHARACTER byte</i>
+	    <LI><b>INT16=1</b><br><i>INTEGER*2 short integer</i>
+	    <LI><b>INT32=2</b><br><i>INTEGER*4 standard integer</i>
+	    <LI><b>INT64=3</b><br><i>INTEGER*8 long integer. (note: this is not
+		availible on the Intel/Windows platform)</i>
+	    <LI><b>FLOAT32=4<br></b><i>REAL*4 32-bit single-precision IEEE
+		float</i>
+	    <LI><b>FLOAT64=5<br></b><i>REAL*8 64-bit double-precision IEEE
+		float</i> 
+	    <LI><b>UINT8=6</b><br><i>unsigned character</i>
+	    <LI><b>UINT16=7</b><br><i>unsigned INTEGER*2 short integer</i>
+	    <LI><b>UINT32=8</b><br><i>unsigned INTEGER*4 standard integer</i>
+	    <LI><b>UINT64=9</b><br><i>unsigned INTEGER*8 long
+		integer. (note: this is not availible on the
+		Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	<DD>Number of dimensions of the dataset
+	<DT><i>dimensions</i>:
+	<DD>An array of <i>rank</i> integers that give the dimensions of
+	  the dataset
+	<DT><i>data</i>:
+	<DD>Your data array. 
+      </DL>
+      
+      So to write a sample array of data.
+      <pre>
+	REAL*4 myarray(40,50,60) // our bogus data array
+	INTEGER i,rank
+	INTEGER dims(3)
+	rank=3
+	dims(1)=40
+	dims(2)=50
+	dims(3)=60
+c this is because ieeeio assumes f77 order for data 
+c and c/c++ use exactly the opposite ordering for data 
+c in memory.
+c   create a outfile
+	INTEGER*8 writer,ieee_openw
+	writer = ieee_openw('datafile.raw')
+	DO i=0,ndatasets
+		. . . . computation . . .
+c 		write a dataset 
+		CALL io_write(writer,FLOAT32,rank,dims,myarray)
+		. . . . you can write as many datasets as you want
+	ENDDO
+c then close the file 
+	CALL io_close(writer) 
+      </pre>
+
+      <hr>
+      <a name="Reading"><h2>Reading Data</h2></a>
+      Reading is a two step process.  First you get information on
+      the size and type of the data you intend to read.  This allows
+      you to allocate an array of the proper size and type for the
+      reading.  Then you actually read the data into a pre-allocated
+      array.  The methods for this are <b>io_readInfo()</b> and
+      <b>io_read()</b>.<p>
+	<b>F77 Call Format</b><br>
+	<code>INTEGER io_readInfo(INTEGER*8 filehandle,INTEGER numbertype,INTEGER rank,INTEGER
+	  dims(*),INTEGER maxdims)</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>A filehandle open for reading or appending.
+	<DT><i>numbertype</i>:
+	<DD>The type of the data being stored
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>.  
+	It can be one of
+	  <UL>
+	    <LI><b>INT8=0</b><br><i>CHARACTER type</i>
+	    <LI><b>INT16=1</b><br><i>INTEGER*2 short integer</i>
+	    <LI><b>INT32=2</b><br><i>INTEGER*4 standard integer</i>
+	    <LI><b>INT64=3</b><br><i>INTEGER*8 long integer. (note: this is not
+		availible on the Intel/Windows platform)</i>
+	    <LI><b>FLOAT32=4<br></b><i>REAL*4 32-bit single-precision IEEE
+		float</i>
+	    <LI><b>FLOAT64=5<br></b><i>REAL*8 64-bit double-precision IEEE
+		float</i> 
+	    <LI><b>UINT8=6</b><br><i>unsigned CHARACTER character</i>
+	    <LI><b>UINT16=7</b><br><i>unsigned INTEGER*2 short integer</i>
+	    <LI><b>UINT32=8</b><br><i>unsigned INTEGER*4 standard integer</i>
+	    <LI><b>UINT64=9</b><br><i>unsigned INTEGER*8 long
+		integer. (note: this is not availible on the
+		Intel/Windows platform)</i>
+	  </UL>
+	<DT><i>rank</i>
+	<DD>Number of dimensions of the dataset
+	<DT><i>dimensions</i>:
+	<DD>An array of <i>rank</i> integers that give the dimensions
+	  of the dataset
+	<DT><i>maxdims</i>:
+	<DD>The maximum size of the dimensions array you given it.
+	  This prevents array overruns if the dataset has more
+	  dimensions than you were anticipating.  It can be any positive
+	  integer.
+      </DL>
+      This retrieves information about the datatype, rank, 
+      and dimensions of the dataset to be retrieved.
+      By default the maximum size of the dimensions array is 3, 
+      but you can set it to be larger.<p>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_read(INTEGER*8 filehandle,<i>sometype</i> data(*))
+	</code><p>
+	This actually reads the dataset into the preallocated array
+	<i>data</i>.<p>
+
+	Another useful utility function is io_sizeof() which returns the
+	number of bytes in a give IO datatype in manner analogous to the
+	standard C sizeof() operator.  This may not be of consequence for most
+	f77 codes.
+
+	So for instance, to read a simple dataset, you would do
+      <pre>
+	INTEGER rank
+	INTEGER numbertype
+	INTEGER dims(3)
+c Note: The "PTR" is the architecture dependent definition of
+c a dynamically-allocated memory handle. (my vary from system to
+c system under F77.
+	PTR data
+	INTEGER*8 infile,ieee_openr
+	infile = ieee_openr('dataset.raw')
+	io_readInfo(infile,numbertype,rank,dims)
+c OK, we are assuming a 3D IO::Float32 array, 
+c but you can be more sophisticated... 
+c Note: The "allocate" statement is a stand-in for
+c your architecture dependent dynamic memory allocation function
+c for your particular system.
+        data = allocate(io_nbytes(numbertype,rank,dims))
+c io_nbytes() is a convenience function.. you can just as easily use
+c	data = allocate(dims(1) * dims(2) * dims(3) * io_sizeof(numbertype))
+	CALL io_read(infile,data) // read in the data
+      </pre><p>
+
+	Since multiple datasets can be stored in a file, you can
+	retrieve them in the order they were written <i>(there is a <a
+	    href="#Seeking">seek()</a> function that allows random access as
+	  well)</i>.  The method <b>io_readinfo()</b> implies reading the next
+	dataset stored in the file.  The method <b>io_numdata()</b> tells how
+	many datasets are in a file. So typically if you want to read all
+	datasets in a file in order, you would use code similar to;
+      <pre>
+	INTEGER*8 infile,ieee_openr
+	infile = ieee_openr('dataset.raw')
+	ndatasets = io_numdata(infile)
+	DO i=1,ndatasets BEGIN
+	  .....lots of code....
+c increments to next dataset
+	  CALL io_readinfo(infile,numbertype,rank,dims) 
+	  .....more code....
+        ENDDO
+      </pre>
+
+      <hr>
+      <a name="Seeking"><h2>Random Access to Datasets
+	  <i>(Seeking)</i></h2></a>
+      You can select specific datasets in a file using the seek()
+      method.<p>
+	<b>F77 Call Format</b>
+	<code>INTEGER io_seek(INTEGER*8 filehandle,INTEGER index)</code>
+      <DL>
+	<DT><i>filehandle</i>:
+	<DD>Handle to a file open for reading.
+	<DT><i>index</i>:
+	<DD>The index of the dataset you want to read from.  This can
+	  be any number from 0 to (number_of_datasets - 1).
+      </DL>
+      
+      <hr>
+      <a name="WriteAttribs"><h2>Writing Attributes</h2></a>
+      Attributes allow you to attach extra information to each
+      dataset stored in the file.  Each attribute has a name and an
+      array of data (of any of the standard IO datatypes) stored with
+      it.  These attributes can be retrieved by name or by integer
+      index in the order in which they were stored.  A typical
+      attribute would typically be parameters that describe the grid
+      or the data like, 'origin' which would be the 3-vector of floats
+      which locates of the origin of a grid in 3-space.  The method
+      used to write these attributes is <b>io_writeAttribute()</b>.<p>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_writeatt(INTEGER*8 filehandle,CHARACTER name(*),INTEGER numbertype,INTEGER
+	  length,(some type) data(*))
+	</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>name</i>:
+	<DD>Name of the attribute (like 'origin' or 'coordinates')
+	<DT><i>numbertype</i>:
+	<DD>The type of the data array associated with the attribute
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the data array.
+	<DT><i>data</i>:
+	<DD>The attribute data.
+      </DL><p>
+	So to write an attribute named <i>origin</i> along with a
+	3-vector float for the coordinates of the origin, you would use;
+      <pre>
+	REAL*4 origin(3)
+	origin(1)=5.
+	origin(2)=0.3
+	origin(3)=0.5
+c and assuming the file is already open for writing
+c the following attribute will be attached to the last 
+c written dataset. (you must have write data before adding attribs)
+	io_writeatt(writer,'origin',FLOAT32,3,origin)
+      </pre>
+
+      <hr>
+      <a name="ReadAttribs"><h2>Reading Attributes</h2></a>
+      The attributes can be retrieved in the order they were written
+      or they can be retrieved by their name.  To retrieve the
+      attributes in order, you would utilize the <b>io_numatt()</b>
+      method to determine how many attributes are attached,
+      <b>io_iattinfo()</b> to get the size and type of the
+      attribute based on its index (<i>use io_attinfo() to get size
+	and type for the attribute based on its name</i>), 
+    and <b>io_readatt()</b> to read the attribute
+      data.<p>
+	<b>F77 Call Format</b><br>
+	<code>INTEGER io_numatt(INTEGER*8 filehandle)</code><p>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>Number of attributes in the file
+      </DL><p>
+	<b>F77 Call Format</b><br>
+	<code>INTEGER io_iattinfo(INTEGER index,CHARACTER name(*),INTEGER
+	  numbertype,INTEGER length,INTEGER maxnamelength)
+	</code>
+      <DL>
+	<DT><i>index</i>:
+	<DD>The index of the attribute which can be 0 to (nattributes-1)
+	<DT><i>name</i>:
+	<DD>A buffer in which the name of the attribute will be placed.
+	<DT><i>numbertype</i>:
+	<DD>The type of the attribute data
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The number of elements in the attribute data.
+	<DT><i>maxnamelength</i>:<DD>The maximum size of a name that can be
+	  stored in the <b>name</b> buffer.  It can be any positive integer.
+      </DL>
+      <p>
+	<b>F77 Call Format</b><br>
+	<code>INTEGER io_readatt(INTEGER*8 filehandle,INTEGER index,(sometype) data(*))</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>index</i>:
+	<DD>The index of the attribute data to read
+	<DT><i>data</i>:
+	<DD>The array into which the attribute data is copied.
+      </DL>
+      So for example, to read the attributes in order, you can use
+      <pre>
+    INTEGER io_numatt
+    CHARACTER*128 name
+    INTEGER length,datatype
+    nattributes=io_numatt(infile)
+	DO i=0,nattributes
+	    ...
+	    CALL io_iattinfo(infile,i,name,&datatype,&length)
+	    ... allocate some data for storage or put in preallocated data
+	    CALL io_readatt(infile,i,data)
+	ENDDO
+      </pre><p>
+
+	The attributes can also be retrieve by name.  In fact, the is
+	the most likely way you will use the attibutes interface.  The
+	<b>io_attinfo()</b> method is overloaded to allow retrieval by
+	name as
+	well.  It returns the index of the attribute if one is found with a
+	matching name: it returns -1 if one is not found.
+      <p><b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_attinfo(CHARACTER name(*),INTEGER numbertype,INTEGER
+	  length)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>The index of the attribute if found or -1 if no attribute with
+	  matching name is found.
+	<DT><i>name</i>:
+	<DD>The name of the attribute to find.
+	<DT><i>numbertype</i>:
+	<DD>Returns the numbertype of the stored attribute data
+	<i>(<a href="DataTypes.html">datatype definition</a>)</i>
+	<DT><i>length</i>:
+	<DD>The length of the stored attribute data.
+      </DL>
+      So a typical use of this interface would be to find an attribute
+      named 'origin' and retrieve its data if it exists.
+      <pre>
+	INTEGER io_attinfo
+	index = io_attinfo(infile,'origin',datatype,length)
+	IF (index.LE.0) THEN 
+c the attribute exists
+		CALL io_readatt(infile,index,data)
+	ELSE
+		write (*) 'The attribute origin could not be found'
+	ENDIF
+      </pre>
+
+    </pre>
+
+      <hr>
+      <a name="WriteAnn"><h2>Writing Annotations</h2></a>
+      An annotation is a text string which can be used to
+      describe a dataset.  To write an annotation, you use the
+      writeAnnotation() method.<p>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_writenote(INTEGER*8 filehandle,CHARACTER annotationtext(*),INTEGER length)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>annotationtext</i>:
+	<DD>A character array of the annotation text
+	<DT><i>annotationlength</i>
+	<DD>The length of the character array
+      </DL>
+      The annotation will be attached to the last written dataset.
+      You can store more than one annotation per dataset and the
+      annotations can be of arbitrary length.<p>
+
+      <hr>
+      <a name="ReadAnn"><h2>Reading Annotations</h2></a>
+      The annotations are stored in the order they are written.  The
+      method <b>io_numnote()</b> is used to find out how many
+      attributes are attached to a dataset.  The method
+      <b>io_readnoteinfo()</b> is used to find the length of the
+      annotation and <b>io_readnote()</b> reads the actual
+      annotation text.<p>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_numnote(INTEGER*8 filehandle)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>returnvalue</i>:
+	<DD>Number of annotations attached to current dataset.
+      </DL><p>
+	<b>F77 Call Format</b><br><code>
+	  io_readnoteinfo(INTEGER*8 filehandle,INTEGER index,INTEGER length)
+	</code>
+      <DL>
+	<DT><i>filehandle</i>
+	<DD>An open filehandle for the datafile.
+	<DT><i>index</i>:
+	<DD>Index of the annotations which can be 0 to (nannotations-1)
+	<DT><i>length</i>:
+	<DD>Length in characters of the annotation.  This includes the
+	  null-terminating character.
+      </DL>
+      
+      <hr>
+      <a name="ReadWriteChunk"><h2>Writing and Reading in Chunks</h2></a>
+      For distributed-memory programming paradigms like HPF, MPI, or
+      PVM, it is often not unfeasible to write data to disk in a
+      single operation.  For this reason, a <i>chunking</i> interface
+      is provided which allows you to write data in blocks to the
+      disk.<p>
+	To begin a chunk writing operation, you must first reserve a
+	data chunk in the file.  This is accomplished using <b>io_reservck()</b>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_reservck(INTEGER*8 filehandle,INTEGER datatype,INTEGER rank,INTEGER dims(*))
+	</code><p>
+	Once space has been allocated in the datafile, you can write
+	blocks of data specified by their dimensions and origin using
+	<b>io_writeck()</b>
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_writeck(INTEGER*8 filehandle,INTEGER dims(*),INTEGER origin(*),(sometype) data(*...))
+	</code><p>
+	Likewise, it is possible to read chunks from the disk as
+	well.  No special procedure is required to select a record to
+	read in chunks. Simply use <a href="#Reading">io_readinfo()</a> 
+	to get the dimensions and
+	type of the dataset and then use <b>io_readck()</b> in place
+	of <b>io_read()</b> in order to read-in the data.
+	<b>F77 Call Format</b><br>
+	<code>
+	  INTEGER io_readck(INTEGER*8 filehandle,INTEGER dims(*),INTEGER origin(*),(sometype) data(*...))
+	</code><p>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John
+	  Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Thu Feb  4 22:02:39 CST 1999
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/UsingIDL.html b/doc/html/UsingIDL.html
new file mode 100644
index 0000000..42f2048
--- /dev/null
+++ b/doc/html/UsingIDL.html
@@ -0,0 +1,154 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>IEEEIO IDL/PV-Wave Interface</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+      <table><tr>
+	  <td><img src="Images/info.gif"></td>
+	  <td><h1>IDL/PV-Wave</h1></td>
+	</tr></table>
+      <hr>
+      <h1>Using the IDL/PV-Wave Interface</h1>
+      The IDL/PV-Wave interface is only for reading.  In the future
+      file writing may be supported, but there hasn't been a need for
+      this as of yet.  The reader is very simplistic right now so you
+      must convert files to native byte order using the <a
+	href="Utilities.html#convert2native">convert2native</a> utility
+      in order for this reader to understand the file.  Likewise,
+      there is support for reading attributes but annotation reading
+      has been delayed due to lack of interest in the short term.<p>
+
+	The procedures are contained in the file 
+	<a href="src/ieeereader.pro">ieeereader.pro</a>.  They can be
+	read into IDL using the command <code>.run
+	  ieeereader.pro</code>.  You can configure this file to
+	autoload by breaking the routines <code>ieeeopen</code>, 
+	<code>ieeeclose</code>, <code>ieeeread</code>, and 
+	<code>ieeereadattr</code>
+	into separate files named
+	<i>procedurename</i><code>.pro</code>.<p>
+
+      <hr>
+      <UL>
+	<LI><a href="#Opening">Opening and Closing Datafiles using
+	    <code>ieeeopen</code> and <code>ieeeclose</code></a>
+	<LI><a href="#Info">Querying the file for the number of
+	    datasets and attributes stored using
+	    <code>ieeendatasets</code> and <code>ieeenattribs</code></a>
+	<LI><a href="#Reading">Reading Datasets using <code>ieeeread</code></a>
+	<LI><a href="#ReadAttribs">Reading Attributes using <code>ieeereadattr</code></a>
+      </UL>
+
+      <hr>
+      <a name="Opening"><h2>Opening and Closing Files</h2></a>
+      Like <code>openr</code> you must open a file handle to access
+      the IEEEIO files in IDL.<p>
+	<b>IDL Function</b><br>
+	<code>filedescriptor=ieeeopen('filename.raw')</code><P>
+	This function opens a file descriptor for reading.  Currently
+	the IDL interface is a read-only interface.<p>
+	To close an IEEEIO filedescriptor and reclaim its resources you
+	use <code>ieeeclose</code>.<p>
+	<b>IDL Procedure</b><br>
+	<code>ieeeclose,filedescriptor</code>
+        Closes the filedescriptor.  It will also deallocate any existing
+        IDL handles when I get this thing converted to use dynamic
+        datastructures.<p>
+      <hr>
+      <a name="Info"><h2>Querying File Information</h2></a>
+      <b>IDL Function</b>
+      <code>ieeendatasets(descriptor)</code><br>
+      Returns number of datasets in the file<p>
+	
+	<b>IDL Function</b>
+	<code>ieeenattribs(descriptor,datasetnumber)</code><br>
+	Returns number of attributes bound to a particular dataset.<p>
+	
+      <hr>
+      <a name="Reading"><h2>Reading Datasets</h2></a>
+      <b>IDL Procedure</b>
+      <code>ieeeread,filedescriptor[,datasetnumber]</code>
+      <DL>
+	<DT>The <b>datasetnumber</b> defaults to 0 if you don't specify
+        <DT>Named Params
+      <UL>
+        <LI><b>RANK = </b>returns rank of dataset
+        <LI><b>DIMENSIONS = </b> returns dims (allocates if none specified)
+        <LI><b>TYPE = </b> Integer datatype...<br>
+	  In terms of IDL datatypes
+	  0=Byte, 1=Fix, 2=Long,3=<i>not availible in IDL</i>,
+	    4=Float,5=Double
+	    <LI><b>DATA = </b> Returns data.  If storage is provided,
+	      then it will
+	      copy into that storage space.  Otherwise it will
+	      allocate.
+      </UL>
+      <DT>The following switches affect Data allocation/management
+      <UL>
+        <LI><b>/INFO</b> : Makes it skip reading the data
+        <LI><b>/ASSOC_1D</b> : Associates data as a sequence of 1D x-columns
+	  (eg data=assoc(unit,xarr(dims(0)))
+        <LI><b>/ASSOC_2D</b> : Associates data as a sequence of 2D xy-slices
+        <LI><b>/ASSOC_3D</b> : Associates data as a sequence of 3D
+	  blocks of data
+	  (note: only block #0 is valid of course)
+        <LI><b>/ASSOC_ELEMENTS</b> : Associates data as a sequence of elements
+	<LI><b>/ALLOCATE</b> : Forces it to nuke any existing data and
+	  allocate
+	  new storage for the data before copying
+        <LI><b>/COPY</b> : Forces it to copy into preallocated data space.
+	  This will force an error if no data is availible
+	  or if the availible preallocated data space is too
+	  small.
+      </UL>
+    </DL>
+      
+      <hr>
+      <a name="ReadAttribs"><h2>Reading Attributes</h2></a>
+      <b>IDL Procedure</b><br>
+      <code>ieeereadattr,descriptor,[datasetnumber]</code>
+      <DL>
+	<DD><b>datasetnumber</b> defaults to 0 if not specified
+	<DD>Named parameters are
+	  <UL>
+	    <LI><b>NUMBER =</b>the index of the attribute (ranges from
+	      0 to nattribs-1)<pr>
+	      nattributes is computed per dataset.
+	    <LI><b>NAME = </b> The name of the attribute.  If you
+	      specify a <i>NAME=</i>
+	      without the <i>NUMBER=</i>, it will search for the attribute
+	      based on its name.  However, if you specify a number
+	      with <i>NUMBER=</i>, it will retrieve the attribute based
+	      on its index and replace the <i>NAME</i> parameter with
+	      the name of the attrib it read.
+	    <LI><b>LENGTH = </b> number of elements in the attribute
+	      data array
+	    <LI><b>TYPE = </b> datatype of the attribute
+	    <LI><b>DATA = </b>  The place to put the attribute data.
+	      If the array
+	      exists and it is the proper size, then it will copy
+	      into the array.  Otherwise it will nuke the array
+	      and replace it with a properly sized one.
+	  </UL>
+	<DD> Data reading is affected by the following flags
+	  <UL>
+	    <LI><b>/ASSOC_ELEMENTS</b> : Associate as an array of elements
+	    <LI><b>/ASSOC_1D</b> : Associate as a 1D array
+	    <LI><b>/COPY</b> : Forces an error if the DATA= you
+	      provided is not the
+	      correct size.
+	    <LI><b>/ALLOCATE</b> : Forces destruction and reallocation
+	      of the array
+	      you provide with <i>DATA=</i>
+	    <LI><b>/INFO</b> : Does not read data.  Just for getting info.
+	  </UL>
+      </DL>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Tue Apr  8 18:57:06 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Wed Apr  9 11:41:11 MDT 
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/Utilities.html b/doc/html/Utilities.html
new file mode 100644
index 0000000..e901176
--- /dev/null
+++ b/doc/html/Utilities.html
@@ -0,0 +1,120 @@
+<html>  
+  <head>
+    <TITLE>IEEEIO Utilities</TITLE> 
+  </head>
+  <body bgcolor="#F0F0F0">
+    <!--<h1>Utilities</h1>
+  <table><tr>
+  <td><img src="Images/info.gif"></td>
+  <td><h1>Utilities</h1></td>
+  </tr></table>
+  <hr> -->
+      <h1>Utilities</h1>
+      <hr>
+
+     <a name="convert2native"><h2>convert2native</h2></a>
+      Converts an IEEEIO file to the native byte-ordering so that reading can
+      occur as efficiently as possible.  The <i>-byteswap</i> flag causes the
+      utility to do the opposite (switch to non-native byte ordering).  Please
+      note that ieeeio does not have any problem reading files of any
+      byte-order, however, byteswapping does exact a performance penalty on
+      any system.  So converting to native byte order improves performance.<P>
+
+	<b>usage</b><br>
+	<code>convert2native [-byteswap] infile outfile</code>
+      <DL>
+	<DT><b>infile</b>
+	<DD>The file to read for translation
+	<DT><b>oufile</b>
+	<DD>The file to write to.  It will be truncated before it is written to
+	  so don't attempt to write to the input file.
+	<DT><b>-byteswap</b>
+	<DD>Forces byte swapping to the opposite of native byte ordering.  The
+	  default is to convert to native byte ordering.
+      </DL>
+
+      <hr>
+      <a name="ioconvert"><h2>ioconvert</h2></a>
+      A more general utility than <b>convert2native</b>; <b>ioconvert</b>
+      converts a file from source format (IEEEIO or HDF) to any allowable
+      destination format (currently only IEEEIO or HDF).  It can also perform
+      byteswapping to convert to native or the opposite of native format.  The
+      default is native format.  <b>convert2native</b> only exists for people
+      who want the byte-swapping capability but don't wish to compile the full
+      HDF libraries.<p>
+
+	<b>ioconvert</b> senses the filetype by the extension you use for the filename. 
+	<i>.ieee</i> and <i>.raw</i> are interpreted as IEEEIO files and
+	<i>.hdf</i> is interpreted as an HDF file.<p>
+
+	<b>usage</b><br>
+	<code>ioconvert [-byteswap] infile{.hdf|.ieee|.raw}
+	  outfile{.hdf|.ieee|.raw}</code>
+      <DL>
+	<DT><b>infile</b>
+	<DD>The file to read for translation
+	<DT><b>oufile</b>
+	<DD>The file to write to.  It will be truncated before it is written to
+	  so don't attempt to write to the input file.
+	<DT><b>-byteswap</b>
+	<DD>Forces byte swapping to the opposite of native byte ordering.  The
+	  default is to convert to native byte ordering.
+      </DL>
+
+      <hr>
+      <a name="ioinfo"><h2>ioinfo</h2></a>
+      Prints out a variety of diagnostic information about IEEEIO and HDF
+      datafiles.  A variety of flags are used to control the amount and the
+      type of information printed.  By default, only information about the
+      datasets (rank, dimensions and datatype) as well as the number
+      of attachments will be printed.<p>
+
+	<b>usage</b><br>
+	<code>ioinfo datafile [-showdata | -hidedata] 
+	  [-showanndata | -hideanndata] [-showanninfo | -hideanninfo] 
+	  [-showattdata | -hideattdata] [-showattinfo | -hideattinfo]
+	</code>
+      <DL>
+	<DT><b>datafile</b>
+	<DD>The file you wish to examine
+	<DT><b>-showdata</b> or <b>-data</b>
+	<DD>Shows the first 10 elements of each dataset.
+	<DT><b>-hidedata</b> [<i>default</i>]
+	<DD>Does not show the data, but shows all information about the
+	  datsets like the datatype and the dimensions etc...
+	  
+	<DT><b>-showannotationinfo</b> or <b>-showanninfo</b>
+	<DD>Shows information about the length of each annotation
+	  bound to a dataset.  Otherwise
+	  only the number of annotations is shown for each dataset.
+	<DT><b>-hideannotationinfo</b> or <b>-hideanninfo</b> [<i>default</i>]
+	<DD>Only the number of annotations is shown for each dataset.
+
+	<DT><b>-showannotationdata</b> or <b>-showanndata</b>
+	<DD>Shows the first 10 characters of each annotation.
+	<DT><b>-hideannotationdata</b> or <b>-hideanndata</b> [<i>default</i>]
+	<DD>None of the contents of the annotations are printed.
+
+	<DT><b>-showattributeinfo</b> or <b>-showattinfo</b>
+	<DD>Shows information about the name, length and datatype of the
+	  attributes for each attribute attached to a dataset.  Otherwise
+	  only the number of attributes is shown for each dataset.
+	<DT><b>-hideattributeinfo</b> or <b>-hideattinfo</b> [<i>default</i>]
+	<DD>Only the number of attributes is shown for each dataset.
+
+	<DT><b>-showattributedata</b> or <b>-showattdata</b>
+	<DD>Shows the first 10 elements of data stored in an attribute.
+	<DT><b>-hideattributedata</b> or <b>-hideattdata</b> [<i>default</i>]
+	<DD>None of the contents of the attribute is printed (except
+	  information if requested).
+      </DL>
+      
+
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Tue Apr  8 19:01:45 MDT 
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/VizReaders.html b/doc/html/VizReaders.html
new file mode 100644
index 0000000..a6e23cf
--- /dev/null
+++ b/doc/html/VizReaders.html
@@ -0,0 +1,109 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>IEEIO Readers</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+      <h1>Readers for Visualization Systems</h1>
+      <hr>
+      <h1>AVS Reader</h1>
+      <a href="http://bach.ncsa.uiuc.edu/Viz/AVS">AVS</a> is a product
+      of 
+      <a href="http://www.avs.com">Advanced Visual Systems Inc.</a>
+      and is very popular for 3D data visualization problems.  The
+      reader for AVS is a module called <b>Read_IEEEIO</b> and
+      provides roughly the same user interface as the HDF reader
+      module provided by NCSA.  You use the file browser to select an
+      IEEEIO file to open (the file extension for this type of file is
+      <i>.ieee</i> or <i>.raw</i>.  If more than one record is found
+      in the file then an integer dial will appear that allows you to
+      select records in the file.<p>
+
+      By default, the module will set the extents of the dataset to be
+      equal to the dimensions of the object with an origin at 0,0,0 
+	(eg. if your object is an array with dimensions {30,40,50}
+	then the extents will be set so that the origin of the data in
+	3D space is {0.0,0.0,0.0} and its maximum extent will be 
+	{30.0,40.0,50.0}).  The module recognizes attributes with the
+	following names
+	(<a href="UsingF77.html#WriteAttribs">F77</a>, 
+	<a href="UsingC.html#WriteAttribs">C</a>,
+	<a href="UsingC++.html#WriteAttribs">C++</a>)<a
+	  href="Using.html">
+	  <img border=0 src="Images/info.s.gif"> </a>
+	<UL>
+	<LI><b>origin</b><br>
+	  This will set the origin (min_extent) of the dataset in 3D
+	  space in AVS.
+	  This can be a vector of Float32 or Float64 numbers with a
+	  length equal to the number of dimensions in the dataset.
+	<LI><b>delta</b><br>
+	  This is the delta-spacing (dx) between elements of the
+	  dataset.  This is multiplied by the number of elements in
+	  the dimension to get the total size of that coordinate of
+	  the dataset.  It normally used with the <b>origin</b> attribute.
+	  This can be a vector of Float32 or Float64 numbers with a
+	  length equal to the number of dimensions in the dataset.
+	<LI><b>min_ext</b><br>
+	  This will treat the dataset as a bounding box and 
+	  set the min_extent of the dataset in 3D space in AVS.
+	  This can be a vector of Float32 or Float64 numbers with a
+	  length equal to the number of dimensions in the dataset.
+	<LI><b>max_ext</b><br>
+	  This works with <b>min_ext</b> and sets the maximum extent
+	  of the bounding box of the dataset in AVS (the max_extent).
+	  This can be a vector of Float32 or Float64 numbers with a
+	  length equal to the number of dimensions in the dataset.
+	</UL>
+      <p>
+	
+      <b>Download Read_IEEEE for AVS</b><br>
+      <UL>
+	<LI><a href="AVSreadIEEE.tar.Z">AVSreadIEEE.tar.Z</a> : 
+	  The full tarred source (the files it contains are described
+	  below).
+	<LI><a href="src/Makefile.AVSreadIEEE">Makefile</a> : 
+	  The makefile to build the module.  
+	  It assumes you have already built <a href="Aquiring.html">libieeeio.a</a>.
+	<LI><a href="src/AVSreadIEEE.c">AVSreadIEEE.c</a> :
+	  The AVS module wrapper for the reader.
+	<LI><a href="src/AVSreadcpp.cc">AVSreadcpp.cc</a> :
+	  The actual guts of the module that does the reading using libieeeio.a.
+      </UL>
+      To compile, you need to change the <b>AVS_PATH</b> variable
+      to point to the root of your avs installation and then type
+      <b>make</b> to build the module.<p>
+      <hr>
+
+      <h1>IDL/PV-Wave Reader</h1>
+      <a href="http://www.rsinc.com">IDL</a> and PV-Wave have a common
+      root in that they originated from a language developed by
+      David Stearns at the University of Colorado.<a
+	href="http://consult.ncsa.uiuc.edu/docs/viz/Idl/"><img
+	  border=0 src="Images/info.s.gif"></a>  Both
+      are now competing products with many differences in their
+      capabilities but the underlying language is pretty
+      much the identical.  So this reader will work in either system.<p>
+
+	Since this is implemented as a native IDL/Wave procedure, you
+	need not compile or link the IEEEIO libraries on your system
+	to make use of this.  It is completely portable since IDL is
+	an interpreted language.<p>
+
+	<b>Download IDL/PV-Wave IEEEIO reader</b><br>
+      <UL>
+	<LI><a href="src/ieeereader.pro">ieeereader.pro</a> : The
+	  IDL/Wave IEEEIO Reader procedure.
+	<LI><a href="UsingIDL.html">Information on how to use the
+	    IDL/Wave IEEEIO Reader</a>
+      </UL>
+
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Tue Apr  8 17:04:45 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Tue Apr  8 18:27:05 MDT 
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/Writer.html b/doc/html/Writer.html
new file mode 100644
index 0000000..d9b04f1
--- /dev/null
+++ b/doc/html/Writer.html
@@ -0,0 +1,172 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+  <head>
+    <title>Simple Unigrid Writer</title>
+  </head>
+
+  <body bgcolor="#F0F0F0">
+      <h1>Simple Unigrid Writer</h1>
+
+      Stores a sequence of multidimensional arrays including physical
+      grid dimensions.  It assumes the grid is spaced uniformly in
+      each dimension.<p>
+
+      <h2>Attribute Specification</h2>
+      The writer stores the dataset with dimensions and datatype
+      (thats standard HDF practice).  In addition, it stores the
+      following NetCDF-style attributes to extend the description 
+      of the data.
+      <dl><DD>
+      <DL>
+	<DT><b>origin</b>
+	<DD>The floating-point origin of the dataset.
+	<DT><b>delta</b>
+	<DD>The physical spacing between grid points in the dataset.
+	<DT><b>min_ext</b>
+	<DD>The minimum coordinate of the dataset in physical space.  
+	  This is actually identical to the <b>origin</b>.
+	<DT><b>max_ext</b>
+	<DD>The maximum coordinate of the dataset in physical space.
+      </DL></dl><p>
+
+      <h2>The API</h2>
+      <UL>
+	<LI><a href="#CPP">C++ Interface</a>
+	<LI><a href="#C">C Interface</a>
+	<LI><a href="#F77">F77/F90 Interface</a>
+      </UL>
+      <hr>
+      <h3><a name="CPP">C++ Interface</a></h3>
+            <DL>
+	<DT><i>constructor</i> <b>Writer::Writer(IObase &filehandle)</b>
+	<DD>The <i>filehandle</i> is an already open IEEEIO or HDFIO
+	 file.  This initializes the reader and attaches it to that
+	  datafile.
+	<DT><i>destructor</i> <b>~Writer()</b>
+	<DD>This flushes all of the necessary file buffer and destroys
+	  the Writer object.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	<DT><b>Writer::setRank(int rank)</b>
+	<DD>Sets the rank (number of dimensions) of the datasets that
+	  will be written.  The default is 3.
+	<DT><b>Writer::setType(int datatype)</b>
+	<DD>Sets the data type datasets written to the file.
+	  The default is Float32 if you don't set this.
+	<DT><b>Writer::setDims(int *dims)</b>
+	<DD>Sets the dimension sizes for data that will be written to
+	  the file.  This assumes you have already set the rank.
+	  There is no default for this parameter.
+	<DT><b>Writer::setOrigin(double *origin)</b>
+	<DD>This sets the real-valued origin of the dataset.  It
+	  assumes the rank has been set. The default is a 0 origin.
+	<DT><b>Writer::setDelta(double *delta)</b>
+	<DD>Sets the real-valued grid spacing in each dimension.
+	  Also assumes the rank has been set.
+	<DT><b>Writer::setParams(int rank,int *dims,int type,
+	    double *origin,double *delta)</b>
+	<DD>Set all of the above parameters in a single call.
+	<DT><b>Writer::write(void *data)</b>
+	<DD>Writes a dataset as defined by set parameters.
+	<DT><b>Writer::reserveChunk(WRFile wrfile)</b>
+	<DD>Reserves a chunk of size defined by the set parameters.
+	<DT><b>Writer::writeChunk(int *dims,int *origin,void
+	    *data)</b>
+	<DD>Write a chunk of data at the specified integer (logical)
+	  origin and of specified dimensions into the space that has
+	  been reserved in the datafile.
+      </DL>
+      
+      <hr>
+      <h3><a name="C">C Interface</a></h3>
+      <DL>
+	<DT><b>WRFile WRbeginFile(IOFile filehandle)</b>
+	<DD>The <i>filehandle</i> is an already open IEEEIO or HDFIO
+	 file.  This initializes the reader and attaches it to that
+	  datafile. This also creates a WRFile pointer for use by the
+	  WRfile API.
+	<DT><b>WRendFile(IOFile filehandle)</b>
+	<DD>This flushes all of the necessary file buffer and
+	  deallocates the WRFile pointer.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	<DT><b>WRsetRank(WRFile wrfile,int rank)</b>
+	<DD>Sets the rank (number of dimensions) of the datasets that
+	  will be written.  The default is 3.
+	<DT><b>WRsetType(WRFile wrfile,int datatype)</b>
+	<DD>Sets the data type datasets written to the file.
+	  The default is Float32 if you don't set this.
+	<DT><b>WRsetDims(WRFile wrfile,int *dims)</b>
+	<DD>Sets the dimension sizes for data that will be written to
+	  the file.  This assumes you have already set the rank.
+	  There is no default for this parameter.
+	<DT><b>WRsetOrigin(WRFile wrfile,double *origin)</b>
+	<DD>This sets the real-valued origin of the dataset.  It
+	  assumes the rank has been set. The default is a 0 origin.
+	<DT><b>WRsetDelta(WRFile wrfile,double *delta)</b>
+	<DD>Sets the real-valued grid spacing in each dimension.
+	  Also assumes the rank has been set.
+	<DT><b>WRsetParams(WRFile wrfile,int rank,int *dims,int type,
+	    double *origin,double *delta)</b>
+	<DD>Set all of the above parameters in a single call.
+	<DT><b>WRwrite(WRFile wrfile,void *data)</b>
+	<DD>Writes a dataset as defined by set parameters.
+	<DT><b>WRreserveChunk(WRFile wrfile)</b>
+	<DD>Reserves a chunk of size defined by the set parameters.
+	<DT><b>WRwriteChunk(WRFile wrfile,int *dims,int *origin,void
+	    *data)</b>
+	<DD>Write a chunk of data at the specified integer (logical)
+	  origin and of specified dimensions into the space that has
+	  been reserved in the datafile.
+      </DL>
+      <hr>
+      <h3><a name="F77">F77 Interface</a></h3>
+      <DL>
+	<DT><b>INTEGER*8 wr_begin(INTEGER*8 filehandle)</b>
+	<DD>The <i>filehandle</i> is an already open IEEEIO or HDFIO
+	 file.  This initializes the reader and attaches it to that
+	  datafile. This also creates a INTEGER*8 pointer for use by the
+	  WRfile API.
+	<DT><b>wr_end(INTEGER*8 filehandle)</b>
+	<DD>This flushes all of the necessary file buffer and
+	  deallocates the INTEGER*8 pointer.
+	  The filehandle that the writer was bound to must be
+	  closed separately though.
+	<DT><b>wr_setrank(INTEGER*8 wrfile,INTEGER rank)</b>
+	<DD>Sets the rank (number of dimensions) of the datasets that
+	  will be written.  The default is 3.
+	<DT><b>wr_settype(INTEGER*8 wrfile,INTEGER datatype)</b>
+	<DD>Sets the data type datasets written to the file.
+	  The default is Float32 if you don't set this.
+	<DT><b>wr_setdims(INTEGER*8 wrfile,INTEGER dims(*))</b>
+	<DD>Sets the dimension sizes for data that will be written to
+	  the file.  This assumes you have already set the rank.
+	  There is no default for this parameter.
+	<DT><b>wr_setorigin(INTEGER*8 wrfile,REAL*8 origin(*))</b>
+	<DD>This sets the real-valued origin of the dataset.  It
+	  assumes the rank has been set. The default is a 0 origin.
+	<DT><b>wr_setdelta(INTEGER*8 wrfile,REAL*8 delta(*))</b>
+	<DD>Sets the real-valued grid spacing in each dimension.
+	  Also assumes the rank has been set.
+	<DT><b>wr_setparams(INTEGER*8 wrfile,INTEGER rank,INTEGER
+	    *dims,INTEGER type,
+	    REAL*8 origin(*),REAL*8 delta(*))</b>
+	<DD>Set all of the above parameters in a single call.
+	<DT><b>wr_write(INTEGER*8 wrfile,(sometype) data(*...))</b>
+	<DD>Writes a dataset as defined by set parameters.
+	<DT><b>wr_reserveck(INTEGER*8 wrfile)</b>
+	<DD>Reserves a chunk of size defined by the set parameters.
+	<DT><b>wr_writeck(INTEGER*8 wrfile,INTEGER dims(*),INTEGER
+	    origin(*),(sometype) data(*...))</b>
+	<DD>Write a chunk of data at the specified integer (logical)
+	  origin and of specified dimensions into the space that has
+	  been reserved in the datafile.
+      </DL>
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+<!-- Created: Wed May  7 12:38:45 MDT 1997 -->
+<!-- hhmts start -->
+Last modified: Wed May  7 16:31:19 MDT 
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/changes.html b/doc/html/changes.html
new file mode 100644
index 0000000..ecdfa24
--- /dev/null
+++ b/doc/html/changes.html
@@ -0,0 +1,37 @@
+changes
+----------
+done
+*1) Should change Long8 to FileHandle * which is a caddr_t
+*2) Should change open() arguments for C to be "r" "rw" "r+" standard
+ANSI.
+*3) Get rid of the IO::Write mode with IO::Create
+*4) For f77, need to have modenames that are consistent with
+	the standard f77 IO names (maybe define in a common block).
+
+*6) Convert all ' to " in the C++ file
+*7) Need to add IOisValid() subroutine to C and fortran libraries.
+	Actually instead, have the IOopen() methods return NULL if failure
+	and do the delete automatically internally!!!!
+	Keep IOisValid() around for the possible SocketIO option since the
+	validity can change in midstream...
+*8) As well as sizeOf() and nBytes() and nElements()
+*9) Need static members nBytes(int rank,int *dims,IO::DataType datatype);
+	nElements(int rank,int *dims,IO::DataType datatype);
+*10) Need to have Unsigned integer types uInt8 uInt16 uInt32 uInt64
+
+
+------------
+Put off
+5) Need to have full prototypes for c++ version with the meaning of the
+returnvalue.
+11) Change the seeking to have "current_dataset" and "ndatainfo".  where
+the ndatainfo is a counter for the number of times datainfo has been
+called.  So it acts as a trigger for incrementing the dataset pointer.
+And that a data info read is not necessary to enable reading other
+things like attributes.  It also makes it easier to determine the
+end-of-file condition.
+-----------
+Might not do
+12) Change datatype names to IOFLOAT32 from FLOAT32 for C.
+
+// need a plan for 64-bit ints on the PC.
diff --git a/doc/html/index.html b/doc/html/index.html
new file mode 100644
index 0000000..84ba7a7
--- /dev/null
+++ b/doc/html/index.html
@@ -0,0 +1,65 @@
+<html>  
+  <head>
+    <title>FlexIO Info</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+    <img src="Images/FlexIO.gif">
+    <hr>
+    <h1>Introduction</h1>
+    FlexIO is a compact API for storing multidimensional scientific
+    data.  It hides the differences between underlying file formats
+    including 
+    <a href="http://hdf.ncsa.uiuc.edu">HDF-SDS</a>, 
+    <a href="IEEEIO.html">IEEEIO</a>, and network socket connections.
+    (<i>Support for HDF5 will be added soon</i>).  It is designed to
+    allow you to use exactly the same subroutine/method calls to store
+    your data regardless of the underlying file format.
+    FlexIO includes C++, C, and Fortran77/F90 interfaces and it has
+    been ported to Sun-Solaris, Digital Unix, Cray-Unicos, SGI-Irix
+    (32 and 64 bit), Windows95 and NT.<p>
+
+      FlexIO borrows its terminology and storage-style from
+      <a href="http://hdf.ncsa.uiuc.edu">HDF and NetCDF</a>.  
+      The file stores a sequence of multidimesional
+      arrays which are referred to generically as <b>datasets</b>.
+      The dimensions and datatype are stored with each dataset so that
+      the data is completely self-describing.  In addition,
+      NetCDF-style named attributes can be stored with each dataset to
+      add information like coordinates, units, and other auxillary 
+      information.<p>
+
+      A set of higher level API's sit on top of FlexIO which permit
+      simplified access to complex datastructures like Finite-Element,
+      Adaptive Mesh Refinement, and Unigrid datastructures.  In
+      addition the MPIO interface provides access to parallel IO for
+      MPI codes.<p>
+
+      <hr>
+      <h1>Information</h1>
+    <DL>
+      <DT><b>Supported Datafile Formats</b>
+      <DD><a href="IEEEIO.html">IEEEIO binary file format</a>
+      <DD><a href="HDFIO.html">HDF 4.x SDS file format</a>
+      <DD><a href="SockIO.html">Network Socket remote file</a>
+      <DT><b>FlexIO API's</b>
+      <DD><a href="Using.html">C, C++, and Fortran programming
+	  interface</a>
+      <DD><a href="HighLev.html">Higher level interfaces for
+	  complex datastructures</a>
+      <DT><b>FlexIO based Software Tools</b>
+	<DD><a href="Utilities.html">Utilities and Data Translators</a>
+	  <DD><a href="VizReaders.html">Readers for Visualization
+	  Systems</a>
+	<DT><b>Getting the Source Code and Compiling</b>
+      <DD><a href="Aquiring.html">Download the source code</a>
+	<DD><a href="Aquiring.html#binaries">Download precompiled libraries</a>
+	<DD><a href="Aquiring.html#compiling">Compiling FlexIO-IEEEIO</a>
+    </DL>
+    <hr>
+    <address><a href="mailto:jshalf@ncsa.uiuc.edu">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Fri May 29 12:31:38 CDT 1998
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/why.html b/doc/html/why.html
new file mode 100644
index 0000000..bccad6d
--- /dev/null
+++ b/doc/html/why.html
@@ -0,0 +1,115 @@
+<html>  
+  <head>
+    <title>Why IEEEIO</title>
+  </head>
+  <body bgcolor="#F0F0F0">
+    <!-- <img src="Images/ieeeiotitle.gif">-->
+      <h1>Why use IEEEIO?</h1>
+      <DL>
+	<DT><b>Its compact</b>
+	<DD>On the SGI Origin 2000, the entire library is 206k.
+	  It contains only a little over 2,500 lines of code for
+	  the C++, C, and F77 versions combined.<p>
+	  
+	<DT><b>Its fast</b>
+	<DD>Most simulation applications end up writing a lot more
+	  data than they read, the I/O interface is optimized for
+	  maximum writing speed. No seeking is required during writing
+	  and the low-level raw unix I/O interface 
+	  is used to maximize performance. 
+	Preliminary <a href="Performance.html">performance tests</a>
+	 show that it is
+	comparable with f77 unformatted IO for writing
+	speed.
+
+	Data is translated to the
+	  machines native representation <i>(ie. byte-swapping)</i>
+	  only during reading. 
+	  If speed is required for reading as well, then there is a
+	  <a href="Utilities.html#convert2native">'convert2native'</a> 
+	utility which will optimize the file
+	  for the type of machine that is reading it.<p>
+	    
+	<DT><b>It interoperates with HDF</b>
+	<DD>If you use HDF-SDS, you should have no problem using IEEEIO
+	  because they share the same programming interface.  You 
+	  indicate the type of file you want to use when you open 
+	  the file.  From there on, the same subroutines are used
+	  for reading or writing data to the file, whether it be HDF
+	  or IEEEIO.  In addition there is an 
+	<a href="Utilities.html#ioconvert">'ioconvert'</a> 
+	utility that can translate
+	either direction between IEEEIO and HDF files and preserve
+	all of the HDF annotations and NetCDF attributes.<p>
+	    IEEEIO doesn't supercede HDF.  It is designed
+	    to be a lightweight IO system which you would use when
+	    the broader functionality of HDF is not required.<p>
+	    
+	<DT><b>It is crash-safe</b>
+	<DD>Since no seeking is required to maintain file integrity
+	  during writes, you will not lose data if the
+	  simulation program exits without having properly
+	  closed the file.<p>
+
+	<DT><b>Most machines use IEEE standard floating point number 
+	    formats</b>
+	<DD>When HDF and XDR were first created, almost every machine
+	  architecture had its own native floating point representation.
+	  There were VAX floats, Cray floats, and Convex floating point
+	  representations... all mutually incompatible.  Now, virtually
+	  every major supercomputer architecture supports IEEE standard
+	  floating number representations.  The primary differences
+	  between number formats now it the byte-order which is trival 
+	  to convert.  
+	  As a result, the XDR and HDF support for platform neutral 
+	  floating point formats is more work than is necessary for
+	  most machines.  By depending on 
+	  IEEE standard number formats, the data storage can be made
+	  much simpler and more efficient. 
+	  If
+	  the machine you use doesn't support IEEE floating point
+	  numbers, then you should continue to use HDF.  Since IEEEIO
+	  interoperates with HDF, this does not require significant
+	  modifications to your code to switch back and forth between
+	  the two.  Currently IEEEIO has been ported to SGI IRIX {5.x,6.x},
+	  IRIX64 6.x, HP-UX 9.01, ConvexOS {on SPP-1200 and SPP-2000},
+	  DEC Alpha OSF/1, and the Cray T3E.  The only machine that is 
+	  not supported is the Cray C90.<p>
+
+      <DT><b>Why not use XDR?</b>
+	<DD>
+	So if the aim is to create a lightweight portable binary file
+	format, this leads to the question of why not use XDR for the
+	encoding?  Well the answer is that in early testing it was
+	discovered that HDF is significantly faster and more efficient than
+	XDR.  So if you really need XDR then you should be asking
+	yourself <i>why not use HDF</i>?<p>  
+
+	Again, this file format is
+	primarily designed to take advantage of the fact that most of
+	the operations that XDR and HDF do to make the data platform
+	neutral are not always necessary given current binary formats
+	for floating point numbers.  It also leads to a very simple-to-parse
+	  file structure which brings us to the next point...
+	<p>
+
+	<DT><b>Simple file structure</b>
+	<DD>Its extremely simple file structure makes it 
+	  easy to build readers in a variety of languages.
+	  This is important for interpreted data processing
+	  languages like IDL because the reader can be implemented
+	  in native IDL instead of writing native methods.
+	  The same is true of Java.  Instead of creating native
+	  methods that directly call the libieeeio interfaces,
+	  the format is simple enough that it can be implemented
+	  using java itself.<p>
+      </DL>
+
+      <hr>
+      <address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
+      <!-- Created: Mon Apr  7 12:52:52 MDT 1997 -->
+      <!-- hhmts start -->
+Last modified: Tue May 27 18:14:25 CDT 1997
+<!-- hhmts end -->
+  </body>
+</html>
diff --git a/doc/html/writef77.f b/doc/html/writef77.f
new file mode 100644
index 0000000..1ca4d2f
--- /dev/null
+++ b/doc/html/writef77.f
@@ -0,0 +1,17 @@
+
+	subroutine openf77()
+	OPEN(UNIT=10,FILE='f77speed.unf',FORM='UNFORMATTED')
+	RETURN
+	END
+
+	subroutine writef77(array)
+	REAL*8 array(64,64,64)
+	WRITE(10) array
+	RETURN
+	END
+
+	subroutine closef77()
+	CLOSE(10)
+	RETURN
+	END
+
author	tradke <tradke@21a6bef8-4479-4f54-8f8d-0db94a2919ef>	2003-08-06 12:23:27 +0000
committer	tradke <tradke@21a6bef8-4479-4f54-8f8d-0db94a2919ef>	2003-08-06 12:23:27 +0000
commit	bf0225505894535a9ae36f02a3f6efa6642c5c00 (patch)
tree	822a739d2aa7568d819e634ced6e26035991b1ef
parent	dfcc3d15b8728f2827b323a77e3f8a9e57ca9904 (diff)