Databases

A database is an abstraction used to represent the container in which all data that is part of a common, aggregate collection is stored. For a typical simulation code, the database abstraction represents a single container in which all fields from all time steps for a given run of the simulation are stored. If, in fact, there are many simulation runs that are part of some larger ensemble of runs, then the database abstraction ought to represent a single container in which all fields from all time steps from all simulations are stored.

In our current software, there are two serious limitations with respect to how we implement the database abstraction.

First, no matter what container abstraction we introduce for our clients to read/write SAF field data, they ultimately interact with the resulting data via a number of other tools outside the current scope of the SAF effort. Many of these tools interact with the data as files in the filesystem. Examples are rm, cp, ls, f_stat, ftp, diff, etc. Granted, as files get larger and larger, these tools become unwieldy. These tools provide a view of the data in terms of files. Because of this, our customers have an expectation and a serious requirement to have control over how a database gets implemented in terms of files.

We have no saf_del_xxx_handle functions for databases because the client always must call saf_open_database to obtain a database handle and saf_close_database to free a database handle

Members

• SAF_NOT_SET_DB [Public symbol]
• saf_close_database [Public function]
• saf_open_database [Public function]
• saf_update_database [Public function]