Cloned SEACAS for EXODUS library with extra build files for internal package management.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

50 lines
2.1 KiB

2 years ago
\chapter{Development of \exo{}}
The evolution of the \exo() data model has been steered by
FE application code developers who desire the advantages of a
common data format. The \exo{} model has been designed to
overcome deficiencies in the EXODUS I file format and meet the
following functional requirements as specified by these developers:
\begin{itemize}
\item random read/write access.
\item application programming interface (API) -- provide
routines callable from FORTRAN, C, and C++ application codes.
\item extensible -- allow new data objects to be added
without modifying the application programs that use the file
format.
\item {machine independent -- data should be independent
of the machine which generated it.}
\item {real time access during analysis -- allow access
to the data in a file while the file is being created.}
\end{itemize}
To address these requirements, the public domain database library
netCDF [3] was selected to handle the low-level data storage. The
\exo{} library functions provide the mapping between FE data objects
and netCDF dimensions, attributes, and variables. (These mappings are
documented in Appendix A.) Thus, the code developer interacts with the
data model using the vocabulary of an FE analyst (element
connectivity, nodal coordinates, etc.) and is relieved of the details
of the data access mechanism. To provide machine independency, the
netCDF library stores data in eXternal Data Representation (XDR) [4]
format.
Because an \exo{} file is a netCDF file, an application program can
access data via the \exo{} API or via netCDF API function calls
directly. Although the latter two methods require more in-depth
understanding of netCDF, this capability is a powerful
feature that allows the development of auxiliary libraries of special
purpose functions not offered in the standard \exo() library. For
example, if an application required access to the coordinates of a
single node (the standard library function returns the coordinates for
all of the nodes in the model), a simple function could be written
that calls netCDF routines directly to read the data of interest.